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ABSTRACT: 

Integrated trading provides both automatic matching trades for trading instruments between 
potential counterparties and video conversational negotiated trades for trading instruments 
between potential counterparties using integrated keystations (202, 204, 206, 208) which are 
selectively connectable together. Each of the keystations (202, 204, 206. 208) includes a data 
input device, such as a keyboard (240) and a mouse (242), and an integrated screen display 
(238), with the keyboard (240) and the display (238) being shared for both the automatic 
matching trades effectuated by the keystation (202, 204, 206, 208) through a matching network 
(220) and the video conversational negotiated trades keystation (202. 204, 206, 208) through a 
separate conversation network (218). An integrated terminal controller (214. 216) is provided as 
a common interface between the keystations (202, 204, 206, 208) and the separate networks 
(218. 220). Transaction data is provided between given keystations (202, 204, 206, 208) in the 
system (200) relating to both automatic matching transactions and video conversational 
negotiated trading transactions through the common integrated terminal controller (214, 216) 
which interfaces with the separate communication paths associated with the automatic matching 
trades (220) and the video conversational negotiated trades (218) effectuated by the keystation 
(202. 204. 206. 208). The integrated terminal controller(214, 216) comprises a conversation 
sen/er (252), a concentrator computer (254), the terminal computers (250) associated with the 
various keystations (202, 204, 206, 208) it sen/es, and a local area network (256) tieing them 
together. Initial access to both types of trades can be obtained at log on. A common ticket 
generation scheme for both types of trades is used so that trading tickets may be collected and 
communicated to a remote back office data base through the integrated terminal controller (214, 
216), via the conversation server (252), irrespective of the type of trade completed. 
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® integrated trading provides botti automatic 
matching trades for trading instruments between po- 
tential counterparties and video conversational nego- 
tiated trades for trading instruments between poten- 
tial counterparties using Integrated keystations (202. 
204. 206. 208) which are selectively connectable 
together. Each of the keystations (202. 204. 206, 
208) includes a data input device, such as a key- 
board (240) and a mouse (242). and an integrated 
screen display (238). with the keyboard (240) and 
the display (238) being shared for both the automatic 
matching trades effectuated by tiie keystation (202. 

3 204, 206, 208) through a matching network (220) and 
the video conversational negotiated trades keystation 
^ (202, 204. 206, 208) through a separate conversation 
<NI network (218). An integrated tennninal controller (214. 
^ 216) is provided as a common interface between the 
^ keystations (202, 204. 206, 208) and the separate 
2 networks (218. 220). Transaction data is provided 
~ between given keystations (202, 204. 206. 208) in 



the system (200) relating to both automatic matching 
transactions and video conversational negotiated 
trading transactions through the common integrated 
temriinal controller (214. 216) which interfaces with 
the separate communication paths associated with 
the automatic matching trades (220) and the video 
conversational negotiated trades (218) effectuated by 
the keystation (202. 204. 206, 208). The integrated 
terminal controller(214, 216) comprises a conversa- 
tion sender (252), a concentrator computer (254). the 
terminal computers (250) associated with ttie various 
keystations (202, 204. 206. 208) it serves, and a 
local area network (256) tieing them together. Initial 
access to both types of trades can be obtained at 
log on. A common ticket generation scheme for both 
types of trades is used so that trading tickets may 
be collected and communicated to a remote back 
office data t)ase through the integrated terminal cor>- 
troller (214, 216). via tiie conversation server (252). 
irrespective of the type of trade completed. 



Xerox Copy Centre 



EP 0 434 224 A2 



STORAGE 
DEVICE 



-205 



FIG.1 



2U 



HOST 
COMPUTER 



—222 



224 — 



MATCHING 

HOST 
COMPUTER 



200 



CONVERSATION 
COHMUNICATION 
NETWORK 



T 



^218 



HATCHING 
COMMUNICATION 
NETWORK 

3 C 



-220 



INTE6RATED 
TERMINAL 
CONTROLLER 



— HCOMVERSATION PRINTE 

TICKET OUTPUT FEED TO i 
BACK OFFICE COMPUTER 



KEYSTATION 



luT k^02 ^20t ! 

"^_^^^-J(EYCTATI^ I 

^CLIENT SITE ^210 ~ 



2a0v 

2n% 



232^ 



lircti«IICit=: 



ICONVERSATtON PRINTER I 



TUT 



EO 



TICKET OUTPUT FEED TO 
BACK OFFCE CO MPUTER 236^1 



INTHjRAJEO 

iKi 



E6RA 
TERMINAL 
[CONTROLLER 



238- 



242- 



-216 



K EYBOA R 



KEYSTATWN 



KEYSTATION- 



-212 



I ^208 

CUEMT SITE 



2 



1 



EP 0 434 224 A2 



2 



INTEGRATED TRADING 



The present invention relates to effectuating 
trades of trading instruments both through auto- 
matic matching, in which buyers and sellers who 
are willing to trade with one another based on 
specified criteria may automatically trade when 
matching events occur satisfying these criteria, and 
through video converstaional negotiated trades, in 
which buyers and sellers who are willing to trade 
with one another may do so through exchanging 
video conversational textual messages, and are 
particularly to the methodology of integrating these 
different types of trades in a system which enables 
individual keystations to accomplish both types of 
trades. 

Infonmation retrieval systems for financial in- 
fomnation. such as stock market type of information 
and money market infomnation, nomially emptoy a 
ti'ansfer of data in a high perfonmance. real time 
information retrieval network in which update rates, 
retrieval rates and subscriber and/or user popula- 
tion are generally very high. An example of such a 
system is REUTERS DEAUNG SERVICE, which is 
used in the foreign exchange market or GLOBEX. 
which is used by the Chicago Mercantile Exchange 
for electronic trading in the commodities market 
Such systems, while providing rapid communica- 
tion capability between subscribers, have been pre- 
viously dedicated to one type of trading capabil'rty. 
albeit video conversation capability to effectuate 
negotiated trades through textual messages ex- 
changed between potential counterparties, such as 
in DEALING, or automatic matching capability to 
automatically effectuate trades t>etween anony- 
mous potential counterparties meeting certain user 
specified criteria, such as in GLOBEX. Each of 
these types of systems have their place in the 
market and serve particular needs where appro- 
priate. However, because of wortd of trading of 
financial instruments and the requisite needs asso- 
ciated therewith are dynamic and rapidly change 
with changes in the surrounding circumstances, at 
one moment it may be desirable to trade anony- 
mously in an automatic matching environment 
while at ttie very next moment it may be desirable 
to openly trade in a video conversational negotiat- 
ing environment or to do tx>th. for the same or 
different trading instruments. Thus. alttKXigh there 
have been successful trading systems doing one of 
tiiese types of trades, tfiere are no known prior art 
systems which effectively integrate both of these 
types of trades in a single system so as to permit a 
trader, using a single keyboard and display screen, 
to selectively switch between the two types of 
ft-ading systems dependent on his own desires and 
needs at any given time in the trading environment 



This is so despite the known technique in ttie prior 
art of tying common keyboard, such as described 
in US-A-4,404,551 , in which a common keyboard is 
used to both communicate with multiple computer 

5 systems and multiplex or dynamically route or se- 
lect video displays on one or more VDUs from a 
plurality of simultaneously provided composite vid- 
eo signal inputs from these multiple computer sys- 
tems in response to unique keyboard generated 

70 character codes. 

In addition, despite known prior ait systems 
which have attempted to integrate voice and data, 
such as disclosed in US-A-4.612.416; 4,598,367; 
4,653.046; 4,475,189; 3.344,401; and 4,635,251. 

IS none of these prior iart systems, has integrated 
conversational trading, to enable negotiated trades, 
with automatic matching trades; to enable anony- 
mously matched trades, in a shared environment 
For example, tfie system disctosed in US-A-4, 

20 598.367 is a financial quotation system employing 
a keypad input and a synthesized speech output 
but does not integrate different types of trading 
transactions in a shared environment Similarty, 
US-A-4. 509.167; 4.612,416; and 4.635.251, which 

26 are not directed to finandal information per se. 
merely disclose systems which integrate voice mail 
in a telephone communication system. US-A- 
4,653.045 and 4,475,189 also disctose telephone 
systems which integrate voice and data, with these 

30 systems being used in telephone conferencing. 
US-A-3,344.401 , discloses another type of tele- 
phone system in which voice is integrated with 
teletype for communicating with a remote data 
processor in an inquiry system; however, tt>e dis- 

36 closed system is not utilized in a dynamic trading 
environment, such as one involving matching trans- 
actions and/or video conversational negotiated 
trades. 

Moreover, automatic matching trading systems 
40 are well known, such as described in US-A- 
3.573.747; 3.581.072; 4,412.287; 4.677.552; and 
4.674.044. as well as in EP-A-90305^: 0.399,850; 
90305763; and GB-A-2,227.625; 2.226,217; and 
2.224.141. However, aitiiough these prior art auto- 
45 matic matching systems are capable of automati- 
cally matching bids and offers, and may employ a 
central or host computer to accomplish this, such 
as disclosed in US-A-4,677.552; 4,674,044; and 
3,573,747; by way of example, they are incapable 
50 of enabling video conversational negotiated trades 
to also occur, thereby requiring a totally different 
system to be empk)yed if tiie trader desires to tfien 
execute such a trade. This can provide significant 
trading disadvantages to the trader. 

In addition, afthough the REUTERS DEALING 
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SERVICE, enables multiple conversations to be 
carried out by a given subscriber in real time and 
in association with data base retrieval of supple- 
mentary data, such as described in US-A-4.531.184 
and 4,525.779, by way of example, as well as in 5 
the aforementioned EP and GB specifications relat- 
ing to video conversational trading systems, none 
of these systems integrates an automatic matching 
trading system with one capable of providing video 
conversational negotiated trades. io 

Apart from the above, there are no known 
trading systems of this type in which a keep alive 
signal is periodically provided to the system in 
order to notify the system that a given subscriber 
keystation is operating properly so that all out- i5 
standing active bids and offers associated witii the 
keystation can t»e automatically deleted from tiie 
trading system if the keystation fails or is unable to 
provide the periodic keep alive signal to tiie sys- 
tem. This enables a trader who becomes mechani- so 
cally locked out from active trading by keystation 
failure to be automatically removed from the trad- 
ing' base so as to ensure that completed trades are 
accomplished only between active traders who are 
able to participate in tiie trading transactions which 25 
are occurring, whether they are anonymous trades 
or negotiated trades. 

Another feature lacking in the known prior art 
relates to the provision of a high speed, reliable 
system for providing a common ticket generation 30 
scheme for providing trading ticket information to a 
t>ack office computer without continual polling, ir- 
respective of tiie type of deal or trade which has 
occunred. Although reliable ticket generation 
schemes are known, such as described in tine 35 
above aforementioned EP and GB specifications 
relating thereto, and although metiiods and sys- 
tems for dynamically controlling the content of a 
local receiver data base from a transmitted data 
base in an information retrieval communication net- 40 
work for collecting financial information are also 
known, such as described in US-A-4.745.559, no 
prior art systems are known which provide com- 
mon ticket generation for automatic matching 
trades and for video converational negotiated 45 
trades, nor are any such prior art systems known in 
which both types of completed trades may be 
stored togetiier for retrieval. 

Thus, there are no known prior art systems or 
methods which can readily combine the advan- 50 
tages, speed and reliability of txTth automatic 
matching and negotiated video conversational 
trades in a single system so as to provide tiie 
individual subscribers or keystations witti maximum 
flexibility and optimal efficiency to effectuate the 55 
type of ti^de demanded by tiie time and circum- 
stances available. These disadvantages of the prior 
art are overcome by tiie method of the present 



invention. 

The present invention is set out in its various 
aspects in ttie independent claims of the present 
application. 

An example of tiie invention will now be de- 
scribed with reference to tiie accompanying draw- 
ings in which: 

Rg 1 is an overall system functional bkx:k dia- 
gram of a system capable of carrying out an 
integrated trading method; 
Rg 2 is a functional bk>ck diagram of a typical 
client site in tiie system of Rg. 1, illustrating a 
typical preferred integrated terminal controller; 
Rg 3 is a functional block diagram similar to 
Rg. 2, illustrating the portion of the presentiy 
preferred integrated terminal controller relating 
to the carrying out of video conversational nego- 
tiated trades; 

Rg 4 is a diagramatic illustration of a typical 

communication network for carrying out video 

conversational negotiated trades; 

Rg 5 is a diagramatic illustration of a typical 

terminal computer associated with a typical 

keystation in the system of Rg. 1 ; 

Rg 6 is a diagramatic illustration, similar to Rg. 

5, of a typical conversation server portion of the 

presently prefenred integrated terminal controller 

of Rg. 2; 

Rg 7 is a functional bkx:k diagram, similar to 
Rg. 4. illustrating the network associated witti 
carrying out automatic matching ti^ades in the 
system of Rg. 1 ; 

Rg 8 is a functional bkxk diagram of tiie net- 
work of Rg. 7 illustrating the flow of information 
in connection with tiie entry of a bki-and the 
entry of an offer in connection with effectuating 
automatic matching trades between potential 
counterparties in tiie system of Rg. 1 ; 
Rg 9 is a functional bk)ck diagram similar to 
Rg. 8. of tiie fkjw of information in tiie networit 
of Rg. 7 in connection with a hit bid or trade in 
connection with tiie canying out of automatic 
matching trades between potential counterpar- 
ties in the system of Rg. 1; 
Rg 10 is a diagramatic illustration of a typical 
integrated video screen display for a typical 
integrated keystation in the system of Rg. 1 
when the small font option has been selected; 
Rg 11 is a diagramatic illustration, similar to Rg. 
10, of a typical integrated video display screen 
layout when matching has been seiected by the 
integrated keystation in Rg.1; 
Rg 12 is a diagramatic illustration, similar to Rg. 
10. of tiie video screen layout of Rg. 11 when 
the video conversational trade option has been 
selected with the display of Rg. 12 toggling with 
tiie display of Rg. 11; 

Rg 13 is a diagramatic illustration similar to Rg. 
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10 of a typical integrated video screen display 
for a typical integrated keystation in the system 
of Fig. 1 when the large font option has been 
selected and the matching trade option has 
been selected: 

Fig 14 is a diagramatic illustration similar to Rg. 
13, of a large font option for a typical integrated 
video screen display of a typical integrated 
keystation in the system of Fig. 1 when the 
video conversational trade option has been se- 
lected, with the screen of Rg. 14 toggling with 
the screen of Rg. 13; 

Fig 15 Is a diagramatic illustration of a typical 
integrated keyboard associated with a typical 
integrated keystation in the system of Rg. 1 ; 
Rg 16 Is an illustration of a typical matching 
ticket produced as a result of a matching trade 
in the system of Rg. 1 ; 

Rg 17 is a diagramatic illustration, similar to Rg. 
16, of a typical conversation ticket produced in 
response to the completion of video conversa- 
tional negotiated trade in the system of Rg. 1 ; 
Rg 18 is a diagramatic state diagram of tiie 
sequence of operations associated with tog on 
and log off a typical integrated keystation in the 
system of Rg. 1 ; 

Rgs 19-20 comprise a logic flow diagram of the 
log on/log off sequence of operations illustrated 
in the state diagram of Rg. 18; 
Rgs 21-24 are diagramatic illustrations of typical 
integrated video screen displays for a typical 
integrated keystation in the system of Rg. 1, 
illustrating the integrated trading capabilities of 
the system of Rg. 1. with Rg. 21 illustrating a 
typical integrated video display in which both 
information relating to automatic matching 
trades and infomnation relating to video con- 
versational negotiated trades is present on the 
screen, but no trade has occurred with that 
keystation, wttii Rg 22 illustrating the screen of 
Rg. 21 with information atx>ut to be transmitted 
in connection wrth completion of a matching 
transaction, with Rg. 23 illustrating the automatic 
matching trade represented in Rg. 21 as having 
been executed and match notification having 
been received by the keystation, and witii Rg 24 
illustrating the integrated display screen of Rg. 
21 when a video conversation negotiated trade 
has been completed; 

Rg 25 is a logic ftow diagram of the operation of 
a typical integrated keystation in tfie system of 
Rg. 1 in response to receipt of a match notifica- 
tion signal; 

Rg 26 is a logic flow diagram, similar to Rg. 25, 
of the operation of a typical integrated keysta- 
tion in the system of Rg. 1 in response to 
receipt of a match ticket or conversation ticket; 
Rgs 27-29 are logic flow diagrams, similar to 



Rg. 25, illustrating ttie operation of a typical 
Integrated keystation in the system of Rg. 1 with 
respect to ttie keep alive feature, with Rg. 27 
illustrating tiie operation of the integrated key- 
5 board, and Rgs. 28 and 29 illustrating ttie op- 
eration of ttie terminal computer portion of tiie 
integrated keystation; 

Rg 30 is a functional block diagram Illustrating 
tiie flow of information in connection with a 
10 typical matching fransaction; 

Rg 31 is a diagramatic illustration of a portion of 
the trading ticket output process utilizable in the 
system of Rg. 1 concerned with the ticket out- 
put protocol; 

75 Rg 32 is a logic flow diagram of a ticket output 
process; 

Rg 33 is a logic flow diagram of the operation of 
the integrated terminal controller when a new 
trading ticket has been generated in accordance 

20 witii the fading ticket output process of Rg. 32; 
Rg 34 is a \oq\c flow diagram of the operation of 
the datat)ase server portion of the integrated 
tenninai controller in ttie system of Rg. 1 vrith 
respect to requests for tickets received by the 

25 database server from a back office computer; 

Rg 35 is a logic flow diagram of the data 
display application for initiating a fast conversa- 
tional contact message using the screen pointer 
in a typical integrated keystation in the system 

30 of Rg. 1 ; and 

Rg 36 is a logic fk>w diagram of the conversa- 
tion application processing of a fast conversa- 
tional contact message initiated in accordance 
with Rg. 35 for expanding tiie contact message 

35 and establishing conversational contact in the 
system of Rg. 1 . 

An integrated trading system 200, as will be 
descrit)ed in greater detail hereinafter, is capable of 
effecting trades of trading instruments botii through 

40 automatic matching, in which buyers and sellers 
who are willing to trade with one another based on 
specified criteria may automatically trade when 
matching events occur satisfying ttiese criteria, and 
through video conversational negotiated trades, in 

45 which buyers and sellers who are willing to trade 
wrtti one antoher may do so through exchanging 
video conventional textual messages. Individual 
integrated keystations, wrth four such integrated 
keystations 202, 204. 206 and 208 being shown by 

50 way of example in Rg. 1. are able to accomplish 
t>otti types of trades. In addition, as will be de- 
scribed in greater detail hereinafter individual 
keystations which are only capable of perfomning 
one of these types of trades can trade with another 

55 keystation of that type or with an integrated keysta- 
tion which is capable of performing botii types of 
fades. In this regard, as shown and preferred in 
Rgs. 1 and 2, an integrated terminal conf oiler with 
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two such client sites 210. 212 being illustrated by 
way of example, in Fig. 1, One such integrated 
terminal controller 214. 218 is illustrated at each 
client site 210. 212. respectively, by way of exam- 
ple, in Rg. 1. 

As shown and preferred In Rgs. 1 and 2, a 
typical integrated terminal controller 214, may ac- 
commodate a plurality of integrated keystations 
202, 204, by way of example, and is the system 
interface for these keystations 202. 204 with the 
other keystations 206. 208 in the system 200 in 
order to enable the different types of trades to be 
effected with these integrated keystations 202, 204, 
206. 208. As shown by way of example in Fig. 1 , 
each type of trade, namely video converstationai 
negotiated trades and automatic matching trades, 
has its own associated communication network 
218, 220 respectively, since the population of in- 
dividual subscribers involved in automatic matching 
trades. In tiiis regard, there is a host computer 222 
assodated with the routing of conversational trade 
and tiiere is a separate matching host computer 
224 which is actually responsible fof the matching 
trades which occur through the matching commu- 
nication network 220. such as described in greater 
detail in the above European publications. Suffice it 
to say that the present control and operation of 
automatic matching trades is preferably the same 
as described in these EP and GB specifications, 
with tfie exception of tiie involvement of the in- 
tegrated tenminal controller 214, 216, with reference 
to a typical terminal controller 214 to t>e described 
in greater detail hereinafter, and the use of tioe 
integrated keystation 202, 204, 206. 208 with the 
operation of a typical integrated keystation 202 to 
be described in greater detail hereinafter. 

A common ticket generation scheme and ticket 
output feed to the back office computer is used for 
both the video conversational negotiated trades 
performed by the system 200 and the automatic 
matching trades performed by the system 200. 
Similarly, with respect to the video conversational 
negotiated trades performed by the system 200. 
these trades are preferably performed in the same 
manner as described in GB-A-2.228.217 and GB-A- 
2,227,625, with the exception, once again of the 
involvement of ttie integrated terminal controller 
214, 216 and the integrated keystations 202, 204, 
206, 208, which enables both this type of trade and 
the automatic matching trades to be integrated in 
the same system 200 and provided on a common 
video display 238. and which provides a common 
ticket generation scheme for t>oth types of trades. 
With respect to the common ticket generation 
scheme, except for the differences to be described 
hereinafter, the ticket generation in the system 200, 
which also describes ttie provision of the ticket 
output fee to tf>e back office computer. 



As shown in Rg. 1, each of the integrated 
terminal controllers 214, 218, has an associated 
ticket printer 226, 228 respectively, and an asso- 
ciated conversation printer 230, 232, respectively, 

5 as well as a ticket output feed 234, 236. respec- 
tively, to its associated back office computer. With 
respect to tiie individual integrated keystations 202. 
204, 206, 208 to be described in greater detail 
hereinafter, a typical integrated keystation 202 pref- 

10 erably has an integrated screen display 238, to be 
described in greater detail hereinafter arKi illus- 
trated by way of example, in Rgs. 10-14 and Rgs. 
21-24, an integrated keyt>oard 240, such as the 
typical keyboard illustrated in Rg. 15. and a cor>- 

75 versational mouse 242 which may preferably be 
used to accomplish fast conversational contact, by 
way of example, such as in the manner described 
in GB-A-2,227,625, and illustrated, by way of exam- 
ple in Rgs. 35-36 which conrespond to Rgs. 11-12 

20 of GB-A-2,227,625. 

As shown in Rg. 2. the integrated terminal 
controller 214 comprises a terminal computer 250 
associated with each keystation. The terminal com- 
puter 250 is preferably a conventional computer 

25 configuration, such as an 80386 Intel 302 computer 
for each Integrated keystation 202. 204, 206. 208, 
In addition, the integrated tenminal controller 214 
also preferably includes a conversation server com- 
puter 252, such as one comprising another 80386 

30 Intel 302 computer, and which is shown in greater 
detail in Rg. 3, and a concentrator computer 254, 
such as a MICRO VAX 2000 computer, for commu- 
nicating with the matching host computer 224 
tfirough the matching communication network 220. 

35 The conversation server 252, the concentrator 
computer 254. and the tenminal computers 250 
associated with the various integrated keystations 
202, 204, for example, are all preferably tied to- 
gether through a conventional local area network 

40 256, such as an Ethernet network, with the cor>- 
centrator computer 254 preferably communicating 
with the conversation server 252 via the keystation 
terminal computer 250 connected to the kx:al area 
networic 256. As shown and prefenred in Rgs. 2 

46 and 3, and as will be described in greater detail 
hereinafter, the conversation server 252. which Is 
shown in greater detail in Rg. 6, not only handles 
video conversational trading, but preferably ties 
together, in the integrated system 200, tiie printing 

50 and ticket generation for tx>th automatic matching 
trades and video conversational negotiated trades 
performed by a given integrated keystation 202, 
204 assodated with that integrated terminal control- 
ler 214, and is the interface with the associated 

55 back office computer for the ticket output feed for 
trades performed at that client site 210, irrespective 
of ttie type of trade performed. 

As shown and prefenred in Rg. 3, aHhough the 
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conversation server 252 is represented by only one 
block in Rg. 2. in reality it may be connprised of a 
line server 264 which enables, for example, the 
provision of context sensitive prompts during con- 
versational trading, such as described in greater 
detail in GB-A-2.226.217. Thus, the conversation 
server 252, such as illustrated in Fig. 6, performs 
several different functions in the system 200 of the 
present invention. The conversation server 252 
handles communications with the conversation 
comunnication network 218, such as DEALING, 
maintains a database with respect to DEALING 
conversations, trade logs and tickets, drives various 
printers 226. 230. analyzes conversations in 
progress, and generates a serial ticket output feed, 
via path 234, for provision of this feed to the back 
office computer. By way of example, in accom- 
plishing this task, the conversation server computer 
252. may. by way of example comprise at least 4 
megabytes of memory, a 40 megabyte hard disk, a 
high density floopy. an Ethernet card with 512 
kilobytes of memory, conventional RS232 Serial 
Connecttons. an STB VGA extra memory video 
card generating a TTL output and the appropriate 
software to communicate with the conversation 
communication network 218. These components 
are illustrated, by way of example, in Rg. 6. With 
respect to the associated printers 226, 230, the 
conversation printer 230 preferably prints conversa- 
tions as they are completed, whereas the ticket 
printer 226 preferably prints a single ticket for each 
matching trade as well as each confinned video 
conversational negotiated trade. Of course, other 
printers may be associated with the integrated ter- 
minal controller 214. such as an audit trail printer 
280 or other standby printers if desired. With re- 
spect to the typical terminal computer 250. such a 
tenninal computer 250 is illustrated in further detail, 
by way of example, in Rg. 5. Thus, by way of 
example, the terminal computer 250 such as an 
Intel 302 PC, which may also be emptoyed for the 
conversation server 252 as illustrated in Rg. 6. 
preferably includes an RS232 input for a serial 
keyboard 240 and a serial mouse 242. a 51 2K 
Ethernet card, a conventional device for driving an 
analog screen 238, a 40 megabyte hard disk, and 
at least 3 megabytes of memory. It should be 
noted, that the terminal computer 250 illustrated in 
Rg. 5 is merely illustrated by way of example, and 
other conventional computers capable of use with 
the system 200 may also be employed instead of 
or in conjunction with terminal computer 250. 

tt should be noted with reference to Rg. 2 that, 
although only one conversation server 252 is illus- 
trated as being connected to the local area network 
256. if desired, a plurality of conversation servers 
252 can be connected to the same section of the 
Ethernet Network 256, with there still being a single 



concentrator computer 254 for supporting matching 
connected to the local area network 256. By way of 
example, each conversation server 252 may sup- 
port up to 1 2 keystations for conversational trading 

5 and matching trades, with the concentrator com- 
puter 254. by way of example, being a Micro VAX 
2000 computer having a Ethemet interface, a hard 
disk, a pair of Asynchronous Serial lines to the 
matching communication network 220. and appro- 

10 priate software, such as refen-ed to in the afore- 
mentioned EP and GB specifications, ft should be 
noted that by way of example, in the instance of 
12 keystations being associated with a given in- 
tegrated terminal controller 214, the 12 keystations 

75 need not all be supported by the same conversa- 
tion server 252. as mentioned above, even though 
the 12 keystations could t^e supported by a single 
concentrator computer 254. 

As will be described with reference to Rgs. 10 

20 - 14, different screen layouts for the integrated 
screen display 238 may be provided, with Rg. 10 
illustrating the small font option preferably for use 
with large video screens such as 12 - 14 inch 
screens, and with Rgs. 13 and 14 illustrating the 

35 large font option preferably for use witii smaller 
video screens such as 10 inch screens or when the 
user requires a simple display. Rgs. 11 and 12 
illustrate the screen layout of tiie integrated screen 
display 238 in which, by way of example, a 14 row 

30 general display area is provided by overiaying the 
matching trade and conversational trade wirtdows 
in the display, with Rg. 1 1 illustrating the integrated 
screen display 238 wtien matching has been se- 
lected by the user at the keystation, and with Rg. 

35 12 illustrating the integrated screen display 238 
when conversational trading has been selected by 
tiie user at tiie keystation, with ttie integrated 
screen display 238 toggling between tiie layout 
illustrated in Rg. 11 and the layout illustrated in 

40 Rg. 12 depending on the option selected. Prefer- 
ably, any of the screen layouts illustrated in Rgs. 
10-14 may be selected by the user at tiie keysta- 
tion for providing the desired integrated screen 
display 238. in this regard, it should be noted ttiat 

46 the keystation may be run under commerdally 
available windowing software, such as Microsoft 
Windows 386 version 2.1. DOS 3.3 and tiie Win- 
dows version of the Workstation Environment 
(WSE). In the screen layout for tiie integrated 

50 screen display 238 illustrated in Rg. 10, tiie current 
entries in the market for potential automatic match- 
ing trades are preferably contained in area 260 with 
tiie results of the particular keystation' s recent 
automatic matching trade activity preferably being 

55 contained in the area immediately betow and given 
reference number 262. As illustrated in Rg. 10. in 
tiie area immediately bek>w tiiat is the window 
which contains conversational trading activity and 
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may, by way of example, contain up to four such 
separate trading conversations of the type referred 
to in the aforementioned patents and EP and GB 
specifications relating to conversational trading. 
This area has been given reference numeral 264. 
Immediately to the right of that area in the screen 
layout iilustrated in Rg. 10 is an area designated 
for displaying incoming calls as well as conversa- 
tion analysis summaries, such as refen-ed to in the 
aforementioned patents and EP and GB specifica- 
tions, with conversation analysis summary being 
described and refenred to in the aforementioned 
GB-A-2,226.217, and with ttiis area being given 
reference numeral 266. In connection with the dis- 
play of multiple tiBdIng conversations in area 264, 
when conversational trading Is selected by tiie in- 
tegrated keystation given the screen layout of Fig. 
10, preferably tiiere is provision for a heading and 
at least 7 lines of the current conversation, and at 
least a heading and 1 line of text for up to three 
more trading conversations. Immediately t>elow 
area 264 is a display area for Dealing or conversa- 
tional trading command responses, with ttiat area 
being designated with reference numeral 268. Be- 
low that area is an area designated as tiie general 
display area, given reference numeral 270, which 
may preferably contain other market related in- 
formation, such as the REUTER MONITOR page. 
The same areas are preferably provided In the 
screen layouts illustrated in Rgs. 11 and 12 with, 
however, the size of the general display area 270 
being increased so as to provide more room for the 
general display area 270 in the screen layout In the 
integrated screen display 238. As can be seen in 
Rgs. 11 and 12, which relate to the same screen 
layout in which the general display area 270 is 
larger, such as 14 rows as compared with the 9 
rows provided in the example of Rg. 10, tfie larger 
size for the general display area 270 is accom- 
plished preferably by overlaying the matching trade 
area 260 and the conversational trade area 264. 
with Rg. 11 illustrating tiie screen layout when a 
matching ti^de option has been selected by the 
integrated keystation and with Rg. 12 illustrating 
ttie same screen layout when a conversational 
trade option has been selected by tiie integrated 
keystation. In this regard, it should be noted ttiat in 
tiie option illustrated in Rg. 11. ttie conversational 
trade area 264 is, by way of example, 15 rows in 
height and the matching trade area 260 is 7 rows 
In height whereas in tiie option illusti'ated in Rg. 
12, the conversational trade area 264 has fc»een 
increased to 22 rows, by way of example, by 
overiaying ttie 7 rows previously used for tfie 
matching area 260. Thus, as previously mentioned, 
the integrated keystation toggles between the 
screen layout of Rg. 11 and ttie screen layout of 
Rg. 12 depending on the trade option selected by 



the integrated keystation. Witti respect to the 
screen layouts illustrated in Rgs. 13 and 14 for the 
integrated screen display 238, these screen layouts 
preferably have tfie same windows as ttie afore- 
5 mentioned screen layouts with, however, the num- 
b>er of rows in various areas being reduced so as to 
accommodate larger characters in ttie display. In 
this regard, in Rg. 13, which illustrates tiie in- 
tegrated screen display 238 layout when matching 

70 has been selected, ttie incoming calls area 266 is 
reduced in size as is the conversational trade area 
264, and the generaJ display area 270 is the same 
size as in the option of Rg. 10. In Rg. 14, when ttie 
conversational trade option has been selected, ttie 

75 matching trade area 260 is overiayed by the con- 
versational trade area 264 which is increased in 
size, by way of example, from the 6 rows of Rg. 13 
to 13 rows in Rg. 14. and tiie incoming calls area, 
which is also used for conversation analysis sum- 

20 mary. 266 is increased in size. Preferably, the 
integrated screen display 238 has a high resolution, 
such as 640 pixels horizontally by 480 pixels verti- 
cally, which is in line with the normal VGA stan- 
dard, with the video being conventionally supplied 

25 by a Windows 386 driver and the STB VGA card in 
the terminal computer 250. 

Refening now to Rg. 15, an integrated key- 
board 240 contains keys which will enable the user 
to participate in both matching trades as well as in 

30 conventional trades in the system 200. For exam- 
ple, such a keyboard 240 may be obtained from 
Reuters, the assignee herein, under the designation 
OKI 01 or AK122/3, wrtti all of ttie integrated key- 
boards 240 on a particular integrated terminal con- 

35 troller 214 preferably being of the same type. The 
system 200 uses keep alive signals from the in- 
tegrated keyboard 240 in order promptiy to detect 
keyboard failure since such failure would effectively 
mechanically disable the trader or keystation from 

40 participating in both matching and/or conversational 
trades through use of the system 200. The keep 
alive signal is preferably a special character which 
is sent to the temninal computer 250 of the keysta- 
tion, at a predetermined periodic interval, such as 

45 every 4 or 5 seconds. This procedure is diagra- 
matically illustrated In Rg. 27. When ttie terminal 
computer 250 receives ttiese special keep alive 
character, it preferably increments a keep alive 
counter, with this procedure being illustrated in Rg. 

60 28. The terminal computer 250 also preferably 
checks at a periodic interval, such as every 5 
seconds, whether tiie keep alive counter has been 
incremented. If the counter has not been incre- 
mented from ttie previous count this indicates to 

55 ttie terminal computer 250 that ttie keep alive sig- 
nal or special character has not been received and 
ttiat, consequently, ttie integrated keyboard 240 
may have failed. This procedure is illustrated in 
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Fig. 29. When the terminal computer 250 detects 
that the keytxxard 240 has failed, the keystation 
removes all entries which it has placed in the 
matching market in connection with potential auto- 
matic matching trades and automatically terminates 
ail its cunrent conversations associated with con- 
versational trading, and off. If desired, an 
alarm can also be provided at the keystation on tiie 
screen 238 indicating that the keyboard has failed. 
Thus, the keep alive signal periodically provided 
from tfie integrated keytx)ard 240 provides a heart- 
beat from the keyboard 240 to the terminal com- 
puter 250, which has been conventionally pro- 
grammed in accordance with the procedures illus- 
trated in Rgs. 28 - 29. and which automatically 
removes the offers and bids associated with that 
keystation from the matching host computer 224 
when it is detected tiiat the integrated keyboard 
240 has failed by failing to provide an appropriate 
hearti>eat or keep alive signal to the terminal com- 
puter 250. Summarizing the above, when a keep 
alive signal is not provided and the terminal com- 
puter 250 detects that it has not been provided 
because tiie keep alive counter has not been incre- 
mented, four actions occur; namely, the user is 
informed that ttie keyboard 240 has failed, the user 
is logged off the keystation, contact is ended in all 
conversations which were active at the time in the 
conversational trading portion of the integrated 
trading system 200, and all prices whrch had been 
input to the matching host computer 224 by ttiat 
keystation in connection with the automatic match- 
ing trading portion of the integrated system 200 are 
automatically removed from the matching host 
computer 224 database. Preferably, as shown and 
prefenred in Rg. 29, if a keep alwe signal is not 
detected in the first instance, tiien ttie tenminal 
computer 250 retries again. If it is not detected 
after the second try, or second beat, then the 
terminal computer 250 indicates that the keyboard 
240 has failed. In this regard, if a mouse 242 is 
provided at tire keystation, preferably, ttie keysta- 
tion may continue to operate if the mouse 242 falls 
as ktng as tiie integrated keyboard 240 is still 
functioning. 

The function of togging on to the matching 
communication network 220 In order to effect auto- 
matic matching trades and to tfie conversation 
communication network 218 in order to effect video 
conversational negotiated trades is integrated in the 
system 200. Rg. 18 is a state diagram illustrating 
the sequence of operations in connection with ttie 
integrated log on/tog off to ttie system 200, with 
Rgs. 19-20 illustrating a logic flow diagram of the 
logic operations performed by the system 200 in 
connection with the sequence of operations illus- 
trated in Rg. 18. Preferably, in order for the user or 
keystation to log on to the system 200. a user 



identifier is required as well as. preferably, a user 
password. Preferably, ttie user identifier is part of 
the set up data in the integrated terminal controlter 
214 and must be entered correctly on tog on for 

5 the user. When this information is entered, the 
server database 262 and the integrated terminal 
controller 214 is accessed in order to obtain tiie 
subscriber name and to check the user I.D. If ttie 
user I.D. is known in the system 200. then the 

70 terminal or keystation 202 for exampto, is checked 
to see If it has been permissioned for matching. If it 
has, then ttie integrated keystation. 202 by way of 
example, tries to log on to tfie matching commu- 
nication network 220 with ttie input password, sub- 

75 scriber name and user 1.0. If tog on succeeds to 
the matching communication network 220 ttie 
keystation 202 has now been logged on to t>oth ttie 
conversation communication network 218 and ttie 
matching communication network 220. since tog on 

20 to the conversation communication network 218 
has not been inhibited. If. however, ttie keystation 
202 cannot log on to the matching communication 
network 220. ttien ttie keystation 202 is preferably 
disconnected from both the matching communica- 

25 tion network 220 and tiie conversation communicar 
tion network 218 and the tog on procedure is 
repeated, starting with the insertion of the user 1.0. 
and password. If, however, matching communica- 
tion for the keystation 202 Is not enabled, as op- 

30 posed to attempting to tog on and failing to log on. 
ttien conversation communication may still be en- 
abled with tiie conversation communtoation network 
218. 

Referring to the log off procedure, assuming 

3S matching communication has not been enabled txit 
conversation communication with the conversation 
communication network 218 had been enabled at 
the time of ttie log off request, ttien ttie system 200 
checks to see if a conversation is in progress. If a 

40 conversation is in progress then the keystation 202 
may not log off. However if a conversation is not in 
progress, ttien tiie keystation 202 may be discon- 
nected from the conversation communication net- 
work 218. Similarly, if matching communication had 

45 been enabled and ttie keystation 202 had logged 
on to both the matching communication network 
220 and the conversation communication network 
218. ttie keystation 202 still couki not log off if a 
conversation was in progress with that keystation 

50 202. The keystation 202 would have to first termi- 
nate the conversation. Furthermore, as shown and 
prefenred in Rg. 20. if a log off request were 
received from tfiat keystation 202 which had been 
logged on to both the communication network 220 

55 and the conversation communication network 218. 
then ttie system 200. and particularly the asso- 
dated integrated terminal controller 214, would first 
determine whether any ti'ading conversation or 
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matching was in progress associated with that 
keystation 202 and, assuming it was not then in 
progress, the terminal controller 214 would then 
determine whether there were any outstanding 
matching tickets expected as a result of trades s 
which had t^n completed but had not yet had a 
ticket generated, tf there were no outstanding 
matching tickets expected, then the keystation 202 
could disconnect from Ixrth matching and con- 
versational trading. If however, there were outstand- io 
ing matching tickets expected, then preferably the 
user would be given the option to confirm a bg off. 
or cancel a log off. or wait for the tickets. If the 
user confirmed a log off or had received the tickets 
after waiting for them, the user coutel then dis- 75 
connect from matching and conversational trading. 
If the user merely cancel led the log off, thten 
conversatfon and matching trading wouW still be 
enabled. This would also be true if a conversational 
or matching trade associated with that keystation 20 
were still in progress. As also shown and prefen-ed 
in Fig. 19. if the keyboard 240 either failed in any 
state in the sequence of operations or was discon- 
nected during any state in the sequence of oper- 
ations, the keystation 202 would be disconnected 25 
from both matching and conversational trading until 
reconnection of the keyboard 202. It should be 
noted from the above, that a keystation 202 may 
solely log on to conversational trading or automatic 
matching trading if that is its capability or desired 30 
intent The purpose of the integrated log on is to 
enable a single keystation 202 to log on to botii 
different types of trading systems, assuming it has 
that capability, with a sir>gle log on procedure. The 
software associated with the log on/log off proce- 3S 
dure illustrated in Rgs. 18 - 20 is contained, by 
way of example, in Table A annexed hereto as an 
Appendbc, and is written in C language for use with 
the 80386 tenminal computer 250 in which this 
software is resident 40 

Referring now to Rgs. 21 - 24, typical screen 
displays for the integrated screen display 238 are 
shown which contain trading Information In connec- 
tion with both matching trades and video conversa- 
tional negotiated trades by the keystation 202 after 45 
it has k)gged on to both the matching communica- 
tion network 220 and the conversation communica- 
tion network 21 a Rg. 21 illustrates the presence of 
both conversational trading data and matching trad- 
ing data on the integrated screen display 23a Rg. so 
22 illustrates tiie same integrated screen display 
238 when tiie YOURS key on the keyboard 240 of 
Rg. 15 has been depressed and ttie YOURS dia- 
logue box is about to be transmitted. Rg. 23 illus- 
trates the same integrated screen display 238 55 
when a matching trade has t>een automatically 
executed and a match notification has been pro- 
vided from the matching host computer 224 to the 
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integrated terminal controller 214 associated with 
the keystation 202. The logic flow diagram illustrat- 
ing the operation of the integrated terminal control- 
ler 214 in response to such a match notification is 
shown in Rg. 25 to be described in greater detail 
hereinafter. Rg. 24 illustrates the same integrated 
screen display 238 with, this time, a conversational 
negotiated trade having been completed as shown 
on the screen and in the conversation analysis area 
268. 

The logic flow diagram of Rg. 25 may be 
accomplished by conventional programming of the 
integrated tenminal controller 214. When the match 
acknowledgment to be described in greater detail 
witti reference to Rg. 9 and EP-A-90305753 is 
received from the matching host computer 224. the 
match is displayed on the integrated screen dis- 
play 238 which was a party to the matching trans- 
action. In addition, an audit trail message is sent to 
the database server 262 which forms part of tiie 
conversation server 252 of the integrated tenminal 
contorller 214 and tiie audit trail is stored at ttie 
database server 262. A reply witti the match num- 
ber is sent to the keystation and when ttie match 
number is receive by the keystation 202 a match 
acknowledgement termed MATCH ACK. is sent to 
the matching host computer 224. As further shown 
and preferred in Rg. 25. tiie dstabese server 262 
rnay also be preferably connected to the audit trail 
printer 280 for printing of audit messages. The 
procedure for printing such audit trail messages is 
also illustrated in ttie logic flow diagram of Rg. 25. 

Rg. 26 is a logic ftow diagram of the operation 
of the integrated terminal controller 214 in re- 
sponse to receipt of a matching ticket or conversa- 
tion ticket at the completion of an automatic match- 
ing trade or video conversation negotiated trade, 
respectively, and may, of course also be imple- 
mented by conventional programming of the in- 
tegrated terminal controller 214. When a match 
ticket is received at ttie integrated keystation 202 
from the matching host computer 224, the match 
ticket Is sent to ttie datat»ase server 262 contained 
in the conversation server 252 of ttie integrated 
terminal controller 214 in the form of what is 
termed a pseudo conversation, with a typical 
matching ticket conresponding to such pseudo con- 
versation being illustrated in Rg. 16. This match 
ticket is then stored at ttie database server 262 and 
can be accessed to support review of displays on 
ttie integrated screen display 238 via the terminal 
computer 250 or to support retrieval of tickets over 
ttie ticket output feed 234 to the back office com- 
puter. Similariy, when a conversation ticket is con- 
firmed at ttie completion of a video conversational 
negotiated trade, tiie conversation ticket which 
may be in the form shown by way of example in 
Rg. 17, is sent to ttie datat>ase server 262 con- 
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tained in the conversation server 252 of the in- 
tegrated terminal controller 214 along with the con- 
versation, the ticket is then stored at the database 
server 262 with the conversation and, like the 
matching ticket, may be accessed to support re- 
view of displays on the integrated screen display 
238 via the terminal computer 250 and to support 
retrieval of tickets over the ticket output feed 234. 
Rg. 26 also illustrates the operation of the printing 
of a ticket, either a match ticket or a conversation 
ticket, by the ticket printer 226 utilizing the ticket 
data stored at the database server 262. 

Apart from the differences described above 
with respect to the employment of the integrated 
terminal controller 214 and integrated keystation 
202 so as to enable the integration of automatic 
matching trades and video conversational negoti- 
ated trades in the system 200. the function and 
operation of tfie various components of the system 
200 relating to the conversation commnication net- 
work 218 and matching communication network 
220 are preferably the same as described in the 
respective aforementioned patents and EP and GB 
specifications which relate to these functions. How- 
aver, for purposes of clarity, certain portions of 
these patent applications shall be repeated herein 
with respect to Figs. 3 and 4 relating to video 
conversational negotiated trades; Figs. 7-9 and 30 
relating to automatic matching trades; and Rgs. 31- 
34 relating to the ticket generation scheme for 
providing the ticket output feed via path 234 or 
236. 

Referring now to Rgs. 3 and 4. as previously 
mentioned, tiie integrated trading system 200, pro- 
vides conversation analysis with respect to tiie 
video conversational negotiated trades effected by 
the system 200. with this conversation analysis 
being summarized in area 266 of the integrated 
screen display 238. This analysis is preferably ac- 
complished in the same manner as described in 
tfie aforementioned GB-A-2,226,217, In which corv 
text sensitive prompts are employed, with ttie con- 
versation analysis software driving the analysis 
driven prompts and letting the user know in real 
time where the user is in the conversation ttiat is 
going on between counterparties, such as foreign 
exchange traders, so ttiat the appropriate prompt 
selection menu may be employed based on the 
analysis of tiie key points in the conversation as it 
proceeds in real time. TTiis real time conversation 
analysis, as described in GB-A-2.226.217. also en- 
ables the preparation of Dealing or conversation 
tickets in real time while tiie deal is being arranged 
through the use of artificial Intelligence techniques 
to analyze the conversation dialog and generate 
the ticket Thus, as described in GB-A-2,226.217, 
tills is accomplished in an expert type of system. 
The context sensitive or analysis driven prompts 



are preferably employed to speed up tiie dealer 
input in connection with video conversational nego- 
tiated trades in system 200 of the present invention 
since time is generally of the essence, such as in 

5 foreign exchange dealings. Of course, the system 
200 need not be limited to foreign exchange deal- 
ing and may be used in connection with any type 
of video communication where rapid input of con- 
versation information is desired. Of course, as is 

10 also descrit)ed in GB-A-2,226.217. tiie system may 
be employed for data capture of offline deals as 
well. Because of this conversation analysis, the 
system 200, is capable of generating enror mes- 
sages to ttie user to alert ttie user if an inconsis- 

75 tency is detected in tiie conversation being ana- 
lyzed in connection with a video conversational 
negotiated trade, such as if the value date is in- 
proper or the range of prices is inproper, by way of 
example. As described in GB-A-2,226.217, apart 

20 from the conversation analysis driven prompts arvj 
associated features, the system is substantially 
similar to other conversational video systems de- 
veloped by the assignee herein and described in 
the aforementioned GB-A-2.227,625. In this regard, 

25 the conversation communication network 218 is 
preferably basically tiie same type of communica- 
tion network as illustrated in Rg. 13J. by way of 
example, of US-A-4,525.779 and the same refer- 
ence numerals have been used in Rg. 4 as are 

30 used in US-A-4,525.779 for like functioning compo- 
nents such as for the concentrators 48 and 110. 
and for the nodes 44 and 42, but with the host 
computer given reference number 38 in Rg. 13J, of 
US-A-4.525.779, and with the storage device hav- 

35 ing been given reference numeral 205 in the exam- 
ple of Rg. 4. The London Taker in Rg. 4 is 
assumed to be the integrated terminal controller 
216 at client site 212 and the New York Maker is 
assumed to be the irrtegrated terminal controller 

40 214 at client site 210. Of course, other packet 
switcfiing communication networks could be em- 
ployed for tiie conversation communication net- 
works 218 in place of the network illustrated in Rg. 
4. The terminal controller shown in Rg. 13J of US- 

45 A-4,525.779 is repteK^ed by the integrated terminal 
controller 214 or 216 in the system of Rg. 1, vwth 
this integrated terminal controller preferably includ- 
ing a conversation analyzing tenminal controller 
portion 214a. such as illustrated in Rg. 3, which 

50 enables real time conversation analysis of the vkj- 
eo conversations between, for example, ttie New 
Yoric Maker at client site 210 and ttie London taker 
at client site 212. and the provision of context 
sensitive analysis driven prompts. In this regard, 

55 and as described in the aforemerrtioned GA- 
2.227.625. conversation tickets may be printed 
based on real time conversation analysis. In addi- 
tion, as was also previously mentioned, the in- 
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tegrated keystations 202, 204, 206, 208 preferably 
also have a conventional mouse 242, such as the 
mouse described in the aforementioned Gb-A- 
2,227,625, such as for providing the fast contact 
features described therein and illustrated in Rgs. 
35-36 which correspond to Rgs. 11-12 of GB-A- 
2,227,625. if these features are not desired, the 
mouse 242 may t>e omitted.. Moreover, it should be 
noted, that both parties to a conversation need not 
have an integrated terminal controller 214, 216 
containing a conversation analyzing tennninal con- 
troller portion 214a, in that the analysis server 264 
may be omitted, however, the party will then not 
have the benefit of real time conversation analysis 
to provide context sensitive or analysis driven 
prompts or automatic ticket generation or inconsis- 
tency notification based on such real time con- 
versation analysis. 

Wrth respect to the conversation anaylzing ter- 
minal controller portion 214a illustrated in Rg. 3, 
the line sender 260, database server 262 and con- 
versation analysis server 264 are all preferably 
80386 computers, such as a COMPAQ 80386 
based computer. In addition, as was previously 
mentioned, the terminal computers 250 are also 
preferably 803^ leased computers, each of which 
provides outputs to its associated integrated screen 
display 238, integrated keyboard 240. and mouse 
242. The previously mentioned kx:ai area network 
256 further permits communication between appro- 
priate ones of the various computers 260. 262, 252 
and 250 in accomplishing the conversation analy- 
sts, context sensitive prompts, inconsistency alert 
and automatic ticket generation functions of the 
system 200. The line server 260 preferably serves 
as an interface between tine terminal computers 
250 and the appropriate concentrator 48 or 110 in 
tiie conversation communication network 218, The 
functions of the database server 262 have already 
been described witii respect to the integrated ter- 
minal controller 214. As for tiie conversation analy- 
sis server 264. this server 264 preferably stores tiw 
conversation analysis software, such as the soft- 
ware described in detail In the aforementioned GB- 
A-2,227.625 and analyzes the conversation in real 
time and provides tfie desired context sensitive or 
analysis driven prompts to the Maker or Taker's 
screen 238. depending on whom the conversation 
analyzing terminal controller portion 214a is asso- 
ciated with at the time, provides conversation tick- 
ets to the datat)ase server 262 associated with it, 
and alerts the user to inconsistencies in the con- 
versation by providing such alerts to the integrated 
screen display 238. Of course, although in tfie 
example of Rg. 3. separate sen/ers 260, 262 and 
264 are shown as comprising ttie conversation 
sen/er 252 of the integrated terminal controller 214, 
these senders can be comt>ined into a single com- 



puter, if desired, with each keystation 202, 204, 
206, 208 still being supported by a dedicated ter- 
minal computer 250 and with, as previously men- 
tioned, these keystation terminal computers 250 
5 being linked to the senders 260. 262, 264 by the 
conventional local area network 256. Preferably, 
communication over tills locai area network 256 
uses a virtual connection such as provided by tiie 
MS-NET standard variant In addition, preferably all 

10 of the data about each conversation in progress, 
such as up to 24 such conversations for a given 
terminal controller 214, by way of example, is held 
in a gtobal array with each element in this array 
pointing to a structure of type CONVDATA in ac- 
ts cordance with the software illustrated, by way of 
example, in ttie aforementioned GB-A-2.227.625. 
This is a type which holds the various network 
handles associated with tiie conversation, the text 
buffer for tiie conversation, and so on. It also 

20 preferably includes an element identified as 
SAVEDDATA of type ANALYSISDATA, which is 
used to store tiie state of the conversation analysis. 
The conversation analysis is driven by the receipt 
of packets of text from ttie various keystations 202, 

25 204. 206. 208 comprising ttie subscriber population 
of tiie conversation communication network 218. 
These successive chunks of text arrive in AN- 
ALYSE TEXT PACKETS which are directed to the 
conrect procedure by tiie environment which has 

30 been infCNrmed of the destination of the input mes- 
sages by a call to NetRegisterReply in tfie proce- 
dure Ov-main in section caserver.c in the software 
described in the aforementioned GB-A-2,227.625. 
The incoming packets of text are directed to tfie 

35 procedure fn ReplyAnalysisMessages in the sec- 
tion camesage.c. When an ANALYSE TEXT packet 
is received for a conversation. (Cunrent Conv) is set 
to point to ttie COINIVDATA structure for ttie appro- 
priate conversation, arxi the saved analysis state 

40 and ticket are preferably copied into the working 
areas pointed to by ttie gtobals (Ticket) and 
(Analysis Data). Then the procedure Re- 
plyAnalyzeText in ttie section camesage.c of the 
software described in ttie aforementioned QB-A- 

45 2,227.625 is called to check ttie request. If appro- 
priate, the arialysis is initialized. This happens 
when text is deleted, for example, by an intenrupt 
Any new text ts added to the conversation and the 
C library procedure se^ump of the aforementioned 

50 software is called to store the current 0 context for 
ttie bngjump retum from parsing. Tliis call to set- 
jump returns zero, and then the parsing routine 
parse of ttie aforementioned software is preferably 
called to analyze ttie conversation from the last 

55 saved state. When the parsing is terminated by 
reaching ttie end of the text currentiy heW, ttie 
longjump call returns to the point at which setjump 
was called with a non zero reply, and the analysis 
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is wrapped up by notifying the keystation 202, by 
way of example, of any change to the analysis. 
Preferably, the conversation analysis, such as ex- 
emplified by the software descrilDed in the afore- 
mentioned GB-A-2,227,625, always starts on the 
parse procedure. 

It should be noted, as described in the afore- 
mentioned GB-A-2,227,625, that preferably conver- 
sation analysis is performed on words or groups of 
symbols which are extracted by nextsym in section 
read.c of the conversation analysis software listing 
described in the aforementioned GB-A-2,227,625. 
Thus, until the conclusion of a stage of analysis, 
the symbols found are preferably stored in a buffer 
so that the analysis can backtrack if the current 
hypothesis proves incorrect, if a reanaJysis is in 
progress, and there is such a queue of extracted 
symbols, nextsym preferably selects the next item 
in the queue. Otherwise, nextsym preferably reads 
a symbol from the text using the routine readsym 
described in the aforementioned software, which 
procedure preferably obtains characters from the 
text buffer using the routine readch. At this stage, 
fully replaceable synonyms, such as PLEASE and 
PLS, are merged to a single symt)ol code, held 
under the identifier (symbol). Other words are pref- 
erably allocated to a symbol such as S cun^ency 
and indtviduaJly identified by a numt>er held in 
(symval). In the case of a cunrency identifier, this 
preferably identifies the actual currency, assuming 
that the conversation is being empk>yed for foreign 
exchange. In addition, as was previously men- 
tioned, the preferred conversation analysis 
software-described in the aforementioned GB-A- 
2,227.625 includes an error detection procedure 
which checks the deals as they occur in real time, 
reporting enroneous or suspect conditions to the 
user based on analysis of the conversation, with 
the error messages preferatrfy being placed below 
the insert line in the integrated screen display 238 
and the suspect fiag data being highlighted in the 
summary analysis display area 266 on the inte- 
grated screen display 238 so as to provide an alert 
It should be noted that in emptoying the conversa- 
tion analysis function in the system 200 the general 
display area 270 in the integrated screen display 
238 may be used to display additional financial 
information, such as a REUTER MONITOR page, 
prompt menus, analysis of the conversations, etc, 
with the analysis of the conversations nomnally 
preferably replacing the REUTER MONITOR dis- 
play. This area 270, may also be used for prompts 
and expanded analyses. Witii respect to tiie start- 
ing of conversations in the integrated system 200. 
such conversations can basically be started in 
tiiree ways; namely, the user can contact another 
dealer, the user can accept tt^e call from another 
dealer, or the user can enter the complete deal. 



using tiie CAPTURE function, as an offline deal. 
The particular menus displayed, preferably depend 
initially on how the conversation is started, with the 
person making the contact normally being referred 
5 to as die Market Taker and the person accepting 
the contact normally being refened to as the Mar- 
ket Maker. 

With respect to ttie printing of conversation 
tickets, assuming conversation analysis is em- 

10 ployed in the system 200, the conversation tickets 
are preferably created in tiie system 200 as tine 
system extracts information by analyzing conversa- 
tions, with the display of the ticket being generated 
appearing on tiie integrated screen display 238. 

IS Preferably, only one analysts can be associated 
with one conversation and, after a user confirms 
the analysis with respect to a current conversation, 
a ticket can be printed on the ticket printer 226 
depending on whether it is the Market Maker or tiie 

20 Market Taker, respectively, when ttie conversation 
is next tenninated or printed. Preferably, the ticket 
printer 226 has tiie same characteristics as the 
conversation printer 230; namely, it accepts serial 
data and it prints on continuous paper. As a con- 

25 versation takes place, the associated conversation 
analysis area on the integrated screen display 238 
preferably shows a summary of the analysis irv 
formation which, if desired, can become a fully 
expanded version of a current analysis which is 

30 then displayed in the general display area 270. 
When the conversation is tenninated and saved, 
preferably tiie analysis is saved with rt Preferably, 
conversations and analyses are saved and deleted 
only as more storage is required. Before conversa- 

35 tion analysis can be confirmed, fnowever, preferably 
it must contain at least the following infonmation 
atx)ut tiYe deal: tiie deal type, the deal direction, 
tiie currency or currencies, the amount, tiie rate or 
rates, and the value date. Thereafter, the user can 

40 confirm the conversation analysis by pressing the 
CONRRM key on tiie keytxjard 240. Once an 
analysis has been set into the confirming mode, 
the next time the conversation is ended on the 
dealer's screen 238. a ticket is preferably printed 

45 and, thereafter, the conversation cannot be edited 
any further. If ttie analysis has not been confirmed, 
it can be marked as cancelled or wrong at any time 
during a real or offline conversation or when wrap- 
ping up a conversation by pressing ttie CANCEL or 

50 WRONG keys on ttie keyboard 240. Thus, in order 
to generate a ticket on ttie ticket printer 226 asso- 
ciated with a video conversational negotiated trade, 
tiie conversation being analyzed is set to the CON- 
RRMINQ state which ends the analysis. 

55 Although a more detailed description is induct 
ed in EP and GB specifications, particularly EP-A- 
90305753. the automatic matching trade compo- 
nent will be briefly described with reference to 
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Rgs. 7-9 and 30. In this regard, Fig. 7 con'esponds 
to Rg. 1 of EP-A-90305753. with the matching 
communication network 220 con^esponding to refer- 
ence numeral 22 in Rg. 1 of this publication, and 
with the central matching host computer 224 cor- 
responding to reference numeral 20 In Rg. 1 of this 
publication.- In addrtion, the client sites in Rg. 7 
have been given reference numerals 210 and 212 
as opposed to the reference numerals 26a and 26b 
employed in Rg. 1 of this publication, since these 
client sites 210. 212 contain the presently pretended 
integrated terminal controllers 214, 216, and with 
the keystations 24a and 24b of Rg. 1 of this 
publication being replaced by the presently pre- 
ferred integrated Iceystations 202, 204. 206. 20a 
Similarly. Rg. 8 corresponds to Rg. 2 of this pub- 
lication with the same exceptions, and Rg. 9 cor- 
responds to Rg. 3 of this publication with the same 
exceptions. Similarly, Rg. 30 conresponds to Rg. 6 
of this publication with the same exceptions with 
respect to the integrated Iceystations 202 and 206 
being substituted for Iceystations 24a and 24b, and 
with the reference numeral 224 being used for the 
central matching host computer 20 employed in 
Rg. 6 of this publication. As shown and prefenred 
Rg. 8, the matching component for effecting auto- 
matic matching trades in the integrated trading 
system 200 is shown in which trading Is effected 
through anonymous matching as opposed to 
through the previously described video conversa- 
tional negotiated trades. Thus. In connection with 
the distributed matching communication network 
220 of the system 200. the matching host com- 
puter 224 serves as a computerised exchange in 
which its central role 15 to identify a buyer and 
seller who are willing to trade with one another 
based on specified criteria, such as price, quantity 
and crecflt When such a matching event occurs, 
assuming the Integrated keystation 202 has logged 
on to the matching communication network 220 in 
the manner previously descrit)ed with reference to 
Rgs. 18-20, preferat>ly the buyer and seller are 
informed of the trade and suffrctent information is 
then provided to them through the respective in- 
tegrated terminal controllers 214 and 216 in order 
to complete the physk:al clearing of the transaction. 
As described in the aforementioned EP and GB 
specifications, in order to support this central funo 
tion. various support functions are required, one of 
which is preferably the maintenance of summary 
market information on the participant's keystation 
integrated display 238 at the various client sites 
210. 212. Preferably, at all times, tiiose keystations 
202, 204, 206 arKl 208 which form part of the 
matching communication network 220 will c^splay 
the bosi inside price for every instrument traded 
tiirough that networic 220. Although all four keysta- 
tions 202, 204. 206. 208 are represented as being 



part of the matching communication network 220. 
as well as being part of the conversation commu- 
nication network 218, this need not be the case. 
The best inside price Is preferably defined to be 
5 ti>e highest value bid and the lowest value offer In 
ttie network 220. Preferably, the prices are dis- 
played together on the integrated screen display 
238 with the quantity bid or offered at the specified 
price so that the trader at the respective integrated 

10 keystation 202, 204, 206 or 208 can observe the 
market activity. By observing the market activity, 
the trader can dedde whether to enter a bid, or 
enter an offer into the market in an effort to com- 
plete a matchir^ transaction, as opposed to the 

16 manner of openly negotiating a trade by exchang- 
ing discretionary messages through the conversa- 
tion communication network 218 to complete a 
video conversational negotiated trade. Thus, with 
respect to tiie client site 210 or 212 to the central 

20 matching host computer 224 will preferably result 
in one or more messages, represented by refer- 
ence numeral 32, going directiy back as a directed 
message to the client site, 210 in this example, 
whrch initiated the transaction mess^. Another 

25 effect of the transaction message 30 being sent to 
the central matching host computer 224 is that for 
certain sorts of transactions, a broadcast message 
34 is generated by the central matching host com- 
puter 224 which is then delivered to all client sites 

30 210. 212 attached to the central matching host 
computer 224 via the matching communication net- 
woric 222. Thus, the directed response or the di- 
rected message 32 only goes back to the particular 
client site 210 and, more particularly, tiie particular 

35 integrated keystation, 202 by way of example, at 
that client site 210 which initiated the transaction 
message, whereas the broadcast message, 34 
goes to all client sites 210, 212 and all the various 
integrated keystations 202. 204, 206, 208 asso- 

40 dated at tiiose client sites 210, 212 which are part 
of the matching communication network 220. As 
was previously mentioned, by way of example, in 
Rg. 7, a typk^ client site 210 is shown as having 
keystations 202 and 204. afthough tiie number of 

45 keystations available at a client site is merely limit- 
ed by ttie capacity of the system and the desired 
processing time. With respect to tiie distribution of 
the functionality in connection with the matching 
communication network 220 of the integrated trad- 

50 ing system 200. tiie matcfiing communk^tion net- 
work 222 preferably does not really play a part in 
that it is transparent to transactional information. By 
this what is meant is that when the transactional 
Information leaves the client site 210. for example. 

55 it could be, if desired, encrypted or garbled in a 
way that tiie only otiier entity which could under- 
stand it wouki be the central matching host com- 
puter 224 and tiiat woukl be in^elevant to tiie func- 

14 



25 



EP 0 434 224 A2 



26 



tion of the matching communication network 222 
since the network does not look at the messages, 
does not process the messages, and merely trans- 
fers these messages to the appropriate parts of the 
matching communication network 220, matching 
communication network 220. the system 200 es- 
sentially maintains a book of bids and offers in the 
matching host computer 224 and a user or keysta- 
tion 202, 206, by way of example, and a client site, 
such as client sites 210 and 212. respectively, 
interacts with the book by submitting bid. offer, hit, 
or take transactions, such as illustrated in Rg. 8. 
The order entry function is preferably convention- 
ally achieved tiirough data entry using tiie inte- 
grated keyboard 240. the mouse 242. or any other 
conventional data entry tool. The matching host 
computer 224 validates the transaction request, 
processes the bid, or tfie hit or take, according to 
the rules of the market, and attempts to find match- 
es between this new entry and the other bids or 
offers posted in the matching communication net- 
work 220 book. If a match is found, then the trade 
is automatically executed, the participants to the 
trade are informed, all databases and trader 
screens 238 are updated as to tfie quantities traded 
and the quantities remaining and. if desired, a 
clearing agency may be informed as to the details 
of the trade so that payment and exchanges may 
be completed. If on the other hand, a match can 
not be found, then the matching communication 
network 220 preferably either disposes of the entry 
for hit or take or keeps the entry for bid or offer for 
later processing. Preferably, in all cases, transac- 
tions are processed to completion according to 
certain rules and the various client sites 210, 212 
preferably receive real time updates of the new 
status of the trading instruments, assuming that 
they are members of the matching communication 
network 220. Thus, as shown and preferred in Rg. 
8. the client site systems 210. 212. only two of 
which are shown by way of example in Fig. 8. 
when the assodated keystations 202. 204, 206. 208 
have selected the matching trade option, submit 
transactions, such as represented by reference nu- 
meral 30 in Rg. 7. to the central matching host 224 
via the matching communication network 222. 

As will be explained In greater detail hereinafter 
with reference to Rg. 30. the submission of a 
transaction 30 from a 



such as to tiie matching host computer 224. In this 
regard, the networic 220 is functioning similar to a 
paired cable in that it is there to pass the infonma- 
tion back and forth. Of course, the networic 220 has 
various other-communication functions which, how- 
ever, for purposes of understanding tiie matching 



component of the integrated system 200. are un- 
necessary to go into. Suffice it to say that prefer- 
ably the matching communication network 220 
uses a protocol which can be termed hierarchal 

5 fan-out in which one node transmits to multiple 
nodes which in turn transmit to multiple other 
nodes. Thus, matching communication network 220 
helps implement broadcast capabilities integrated 
with a message switching network to achieve full 

70 tolerance in broadcast distribution. It should t>e 
noted, when a match occurs, the central matching 
host computer 224 will preferably send directed 
messages or responses to all of those parties in 
the system 200 that were involved in tiie match, so 

75 that in some instances 2.3 or more client sites 
210. 212 may be involved in receiving the directed 
message. However, this still differs from the broad- 
cast message which is sent to ail client sites ir- 
respective of their involvement in a particular 

20 match. 

Referring rww to Rg. 8, this figure illustrates a 
typical data flow in the integrated system 200, for 
the entry of a bkJ or entry of an offer, with the 
matching communk:ation network 220. as was pre- 

25 viously mentioned, being transparent to transac- 
tional information integrated keystation 202. by way 
of example, submits a bid transaction to the central 
matching host computer 224 through tfw matching 
communication network 220, via tiie terminal com- 

30 puter 250 and the concentrator computer 254. The 
directed message or directed response 32 whteh It 
receives t>ack from the central matching host com- 
puter 224 is tenmed a bid acknowledgment or BID- 
ACK. TTiis acknowledgment Is a command ac- 

35 knowledgment which is preferably followed by an 
entry position message and is. as previously men- 
tioned, directed directly back to the keystation 202 
via the concentrator computer 254, the local area 
network 256. and the tenmina) computer 250. In 

40 addition, as shown and preferred in Rg. 8, a bid 
update message is broadcast by the central match- 
ing host computer 224 to all keystations 202, 204, 
206, 208 in tiie system 200 which have logged on 
to the matching communication network 220, such 

45 as represented by reference numeral 34a in Rg. 8. 
This broadcast message 34a preferably occurs if 
this new bid 32a was a new best bid in tiie system 
200 with respect to tiie matching component or 
was an additional quantity being bid at the best 

50 price in the system 200 with respect to tiie match- 
ing component Thus, if this new bid 32a is at the 
highest price or t)etter or higher, then it will result 
in a bid update broadcast message 34a going out 
throughout ttie system 200 to all keystations which 

55 have logged on to tiie matching communication 
network 220. In addition, as also shown by way of 
example in Rg. 8. if it is desired to disseminate an 
external ticker 60. then tiie ticker infomiation 60 will 
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also be provided of the best bid or best offer. 
Preferably, the same procedure is followed wrth 
respect to entry of an offer whh the messages, in 
this instance, being identified as offer, given refer- 
ence numeral 51, offer acknowledgment or OFFER- 
ACK, given reference number 32b, and the broad- 
cast message for offer update, being given refer- 
ence numeral 34b. 

Referring now to Rg. 9, the data flow in tfie 
integrated system 200. Is Illustrated with respect to 
a situation in which there was a hit bid resulting in 
a trade. In this situation, tfiere is substantially more 
activity than the situation previously described wrth 
reference to Rg. 8. Thus, as shown and prefen-ed 
in Rg. 9, If the integrated keystation 206 submits a 
transaction called "hit bid", represented by refer- 
ence numeral 62, to the central matching host 
computer 224 via the matching communication net- 
work 220. a hit acknowledgment or HIT/ACK, repre- 
sented by reference numeral 64. is provided back 
to keystation 206 as a directed message. At that 
point the central matching host computer 224 will 
recognize that a match is possible because the "hit 
bid" message says that keystation 206 is willing to 
trade at the bid price. Assuming that credit is OK 
and does not play a role t)eyond that in this trans- 
action, the central matching host computer 224 
determines that a match is possible but, preferably. 
t)efore committing to the match, it may get in- 
voh/ed in a risk limiting protocol using a transaction 
desk 70, as described in the aforementioned EP 
and GB specifications which determines whether 
the trade is possible, and if so, acknowledges this 
to tfie certtrai matching host computer 224. Assum- 
ing that a trade is possible, ttien a match occurs. At 
that point several messages are generated from the 
central matching host computer 224 through the 
matching communication network 220. One of 
these messages is termed the match message, 
given reference numeral 65. which is a directed 
message that goes to the bidder, which in this 
instance is keystation 206, and to the keystation 
202, which originally owned the bid. Thus, in this 
instance directed nmssages go to more than one 
integrated keystation 202. 206 logged on to the 
matching communication network 220. Preferably, 
every match must be acknowledged so there is a 
match acknowledgment message, MATCH-ACK 
which comes back from ttie buyer and seller 
keystations 202 and 206 and is used to determine 
that the match was in fact received correctly and 
that the deal can be considered complete at that 
point The response of the integrated terminal con- 
troller 214. 216 to such a match notification has 
t>een previously discussed with reference to Rg. 25 
which represents software resident in the various 
terminal computers 250 associated with the keysta- 
tions and in the integrated terminal controllers 214. 
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216, themselves, in the respective data servers 
262, as a result of conventional programming. In 
addition, a broadcast message is generated that a 
trade has occurred which trade update message, 

5 given reference numeral 67. may possibly cause a 
new best bid to occur or coukj affect the quantity 
or price at the top of the t>ook. Again, if the trades 
and best bids go into the ticker 60. then this 
information is provided to the ticker as well. Simi- 

10 larty, if clearing information is provided to a clear- 
ing house, this too occurs as represerrted by refer- 
ence numeral 89. In addition, as shown and pre- 
ferred . trade tickets may also be generated, such 
as previously referred to with reference to Rg. 26. 

75 Thus, trade ticket informatk>n is also preferably 
provided to the participating integrated keystations 
202, 206 in the above example, so that the trade 
tickets can be generated with respect to the match- 
ing trades. 

20 It should be noted that the concentrator con)- 
puter 254. which interfaces with the matchir>g com- 
munication network 220, preferably always commu- 
nicates with the associated conversation server 252 
containing the datat)ase server 262 which controls 

25 the ticket generation, via the keystation terminal 
computer 250. Thus, the concentrator computer 
254 and the conversation server 252 are tied to- 
gether in the integrated tenninal controller 214, 216 
through the local area network 256 and the asso- 

30 ciated keystation terminal computers 250. Conse- 
quently, the software associated with the "ticket 
received" function illustrated in Rg. 26. which may 
be accomplished by conventional programming, is 
resident in the terminal computers 250 associated 

05 with the individual keystations and in the data ser^ 
er 262 portion of the conversation server 252 in the 
integrated terminal controller 214, 216. 

With respect to the details of the various books 
employed in the distributed matching component of 

40 the integrated trading system 200, these details are 
described in the aforementioned EP and GB speci- 
fications. Suffice ft to say that the central matching 
host computer 224 maintains a host book database 
comprising alt of the active fcH'ds and offers In the 

45 integrated trading system 200 which have been 
provided by keystations which have logged on to 
the matching communication networic 220 arxl that 
each of the respective integrated keystations 
logged on to the matching communication network 

50 220 has an associated k)cal data base keystatk)n 
book which comprises a subset of the host book, 
with the content of each of the keystation books 
having an associated display depth range control- 
lable by the central matching host computer 224 

55 and being updatable by transaction update broad- 
cast messages received from the matching host 
computer 224 through the matching communication 
networic 220. In this regard, reference is made to 



16 



29 EPO 



Rg. 30 which illustrates the two collections of in- 
formation which are being maintained at the client 
sites 210, 212 which have logged on to the match- 
ing communication network 220. As shown by way 
of example in Rg. 30, one of these collections of 
information Is the bool< for each instrument which is 
maintained at the keystation sites, 202 and 206. in 
the above example, and have been given reference 
numerals 112 and 110 respectively in Rg. 30. 
Another book maintained at each site is a local 
entry data base or order book which has been 
given reference numerals 116 and 114. respec- 
tively, in Rg. 30. As previously mentioned, there is 
also the host or system book data base associated 
with the central matching host computer 224 which 
has been given reference numeral 118 in Rg. 30. 
Each time a client site 210 or 212. by way of 
example, starts up as an integrated keystation log- 
ging on to the matching communication network 
220. such as by using the log on software and 
procedure illustrated by way of example in Rgs. 18 
- 20 and in Table A annexed hereto as an Appen- 
dix, which is written in C language for use with an 
80386 computer, and which is resident in the termi- 
nal computer 250 of the integrated keystation, the 
integrated keystation which is logging on to the 
system 200 is preferably initially empty and re- 
quests download of the cunrently active books from 
the matching host computer 224. Preferably, sepa- 
rate books are maintained for each trading instru- 
ment and each of these books is maintained at a 
given display depth. In this regard, it should be 
noted that an update broadcast message is prefer- 
ably only broadcast when the price infonmation is 
inside the assigned display depth that has been 
assigned by the matching host computer 224. With 
respect to the local entry datat>ase or order books 
114, 116, these order books 114. 116 are prefer- 
ably updated by directed messages from the 
matching host computer 224 and/or record the 
orders of the particular integrated keystation 202. 
206, by way of example, which had been sent to 
the matching host computer 224 through the 
matching communication network 220. In this re- 
gard, these order books 114. 116 are preferably 
kept current so that there Is a listing only of orders 
which are still present in the central matching host 
computer 224 from the respective integrated 
keystations 202 or 204, by way of example. 

This order database 114 and 116 gets modi- 
fied, such as through the removal of data, due to 
various occurrences, such as when a complete 
match has occurred for a given order and an entry 
remove message is provided, or If it is a partial 
match you may get an entry message that tells you 
that only a partial match has been done against 
that order. The match notification, which was pre- 
viously refenred to. preferably refers to a particular 
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order that is contained in the order database 114 or 
116 and indicates what quantity or portion of the 
order has been matched. If all of the order has 
been matched, the entire order is then preferably 

5 deleted from the respective order database 114 or 
116. By way of example, if a bid were put In for ten 
million yen at a price of 127 and the display was 
enabled, that is the display depth was set to some- 
thing greater than or equal to one, then the central 

10 matching host computer 224 would preferably con- 
struct a broadcast message, which is the afore- 
mentioned update broadcast message, which 
woukj infonn all client sites 210,212 that a new bid 
had been added to the Yen t)ook. assuming that 

IS were the instrument bslng traded. The update mes- 
sage woukj instruct an operation block which would 
say add to index one the ten million at 127. As for 
the other parameters in the update message, add 
index would equal one. type wouki equal bid. quote 

20 would equal 127, and quantity would equal ten 
million at 127. As for thie other parameters in the 
update message, add index wouU equal one. type 
wouki equal bid. quote woukj equal 127 and quan- 
tity would equal ten million. In the atx)ve example. 

25 the transaction achieves two functions. The first 
function it achieves is that a bid is submitted and 
the matching host computer 224 responds to the 
integrated keystation 202 submitting the bid that 
the t>id was accepted and that tiiere was no am- 

30 biguity in tiiat tiie bkj is definrtety in the system 
200; tf>e system 200. namely the matching host 
computer 224. has it and the local entry database 
116 has it The other function indk^ates that the bid 
was of a certain characteristic tiiat the rest of the 

35 "matching trading woHd" in the system 200 should 
know about and this is accomplished as a result of 
the broadcast message which was generated to ail 
of the client sites 210. 212 logged onto the matcf)- 
ing network 220. which were ti)en told about this in 

40 summary as opposed to being given all of tiie 
detailed information. It sfioukj be noted that as 
previously mentioned, in terms of functional opera- 
tion, the entry of a bid to the system is the same 
as entry of an offer. 

45 In the situation when a trade occurs, tiiis 
means that a matching offer is present in the 
system, the matching host computer 224 has ac- 
cepted that matching offer, and sends back the 
acknowledgment command, in effect retrieving the 

50 existing book on Yen. in the above example, finds 
out that there is ten million yen at 127 in the book, 
adds to that tiie newly entered fifteen million at 
127, and is aware that it has positioned fifteen 
million at 127. The nrwtching host computer 224 

55 then does ttie match up including that ten million 
and does the trade, taking out the existing bid, so tt 
. reduces tiiat amount to zero million at 127 leaving 
over five million at 127 on the offer side. In this 
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instance, as will be further explained with reference 
to Rg, 30, at least two directed messages have 
been sent actually four having been transmitted to 
the client sites 210.212 that are involved in the 
trade. The seller will get an indication that his Yen s 
bid has traded by means of a match notification 
and he will, thereafter, be informed who the coun- 
terparty was after the match has been made. The 
clearing and settlement of the trade will then pref- 
erably be the responsibility of the subscribers. The io 
counterparty who originally transmitted the offer 
and entry position message saying that it had a 
Yen offer positioned greater than the bid will then 
get an entry positioned yen offer at five million at 
127 and will get a match notification saying that, 75 
with respect to his offer, ten million of his original 
fifteen million has traded with the party who will 
then tie identified. l.astly. the update broadcast 
message will be constructed and broadcast to all 
client sites 210. 212 logged on to the matching 20 
network 220 to update the trading book. That up- 
date message wilt preferably, in the above exanv 
ple, contain two operation blocks, one which will 
remove the bid information from the client book 
and the second which will post the new five million 25 
offer which remains on the offer side and will show 
that a trade took place. In addition, as was pre- 
viously mentioned, if desired, ticker infomnation will 
also be provided in the update message saying 
what traded, keeping track of the cummulative vol- 30 
ume« the net change, the number of changes, the 
high limits, the low limits and so forth, ft should be 
noted tiiat preferably only the integrated keystation 
that either executed the transaction, for example 
keystation 202, or was involved somehow in that 3s 
transaction will receive the directed message with 
respect ttiereto and not other integrated keyst£t- 
tions. such as keystation 204, at the same client 
site 210, whereas with respect to broadcast mes- 
sages all integrated keystations logged on to the 40 
matching network 220 at all client sites receive 
these messages. If desired, with respect to credit, 
ttiis can be controlled on a client site by client site 
basis as opposed to a keystation basis. Thus, in 
the system 200, the matching communication net- 45 
work 220 has two functions, one of whteh is di- 
rected message delivery and the other of which is 
broadcast message delivery. 

Refening now to Rg. 30 in greater detail, the 
matching communication network 220 which, as so 
was previously mentioned, is transparent to trans- 
actional information, has t>een omitted for purposes 
of explanation of the message flow in the system In 
accordance with the miathod of the present inven- 
tion. For purposes of the example of Rg. 30, in- 55 
tegrated keystation 202 can represent any keysta- 
tion which originates a transaction and integrated 
keystation 206 can represent any keystations which 



are involved as counterparties in the transaction 
which, as was previously mentioned can be more 
than one keystation at more than one location. The 
keystations 202 and 206 are normally remotely 
located from each other such as. for example, 
keystation 202 being at a client site 210 in New 
Yori< and keystation 206 being at a client site 212 
in London, which are the same locations used in 
tiie example of Rg. 4 relating to tfie transaction of 
video conversational negotiated trades, although 
the ^cations need not be the same. 

In addition, the keystations 202 and 206 are 
remotely located from tiie central matching host 
computer 224. In order to understand the message 
flow illustrated in Rg. 30. we will assume that the 
originating keystation 202 is receiving a display of 
the keystation tx»ok datat»ase located at keystation 
202 on its integrated screen display 238. Assuming 
that the operator at the integrated keystation 202 
then desires to enter a bid or an offer, either of 
which will be termed an order, this information is 
input to the keystation 202 via conventional means, 
such as the integrated keyboard 240 or a mouse 
242, by way of example. The keystation 202 then 
preferably validates the order and maintains its 
local order data base or local entry data base 1 16. 
The order, instead of being a bid or an offer, could 
be a hit or a take for a particular trading instrument 
as well since ail of these various items woutel 
constitute an entry of an order. After the order has 
tteen entered, validated, and, tiie order data base 
116 maintained, a transaction message is built and 
sent as a directed message to the central matching 
host computer 224 tiirough the( matching commu- 
nication network 220. This is represented by refer- 
ence numeral 120 in Rg. 30. This transaction mes- 
sage 120 is received by ttie central matching host 
computer 224 and contains transaction information. 
At this point, preferably tfie central matching host 
computer 224 sends back a directed message, 
termed a command acknowledgment message and 
given reference numeral 122. to inform integrated 
keystation 202 ttiat tiie transaction message 120 
has been received. The transaction message 120 is 
time-stamped by the central matching host com- 
puter 224 at this point Preferably the display 238 
of keystation 202 will indicate "please wait" until 
the transaction message 120 has b»een acknowl- 
edged. Preferably, such acknowledgment happens 
relatively quickly, such as in about two seconds, by 
way of example. The central matching host com- 
puter 224 then preferably processes the transaction 
message 120 against the central matching host 
computer 224 stored copy of the system or host 
book whrch Is contained in the host book data base 
118. At this point the central matching host com- 
puter 224 preferably either adds ttie entry of ttie 
transaction or the order from integrated keystation 
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202 to the host book data base 118 or matches 
that entry against existing bids and offers contained 
in the host book data base 118. Once that process- 
ing is completed, the central matching host com- 
puter 224 is ready to generate output messages 
not only to the originating keystation 202, but pos- 
sibly to other keystations, such as the counterparty 
keystations represented by 206 and. assuming that 
an update message is required, to ail keystations 
which have logged on to the matching communica- 
tion network 220. Thus, matching host computer 
224 generates directed messages back to each of 
the keystations invoh^ed in the matching transac- 
tion, such as the originating keystation 202. andl 
assuming that there is a match, keystation 206 as 
the counterparty keystation, and generates tiie up- 
date broadcast message to all keystations logged 
on to the matching network 220. It should be noted 
that, as previously mentioned, a single transaction 
message 120 from keystation 202, whether it is a 
hit. or a take, or a bid, by way of example, could 
result in multiple matches. For example, if keysta- 
tion 202 wants to hit the bid for a quantity of 20. it 
is possible that to satisfy tiiat order more than one 
match coukJ be involved such, as for example, four 
or five different matches, particularly, since the 
keystation book at keystation 202 merely displays 
accumulated summaries of the bids or offers. 

If multiple matches occur, then, thereafter, the 
identity of all of the counterparties involved In ttie 
multiple matches are displayed on the integrated 
screen display 238 of the originating keystation 202 
for settlement purposes. Thus, on any given trans- 
action, there will always be directed nnessages 
involving the transaction originator and involving 
one or more counterparties or affected parties in 
that trade or transaction. If the market is an auction 
market, then it preferably has a price depth of one 
so that this determines how many prices the cen- 
tra\ matching host computer 224 can maintain wrtfi 
only one price being maintained in an auction 
maricet When a new bid goes in which betters the 
existing bid In an auction market, the existing bid is 
actually removed and effectively cancelled in the 
book. Preferably, after all of the directed messages 
are generated to the counterparties, and the asso- 
ciated directed message acknowledgments, such 
as represented by reference numerals 124. 128. 
128 and 130 in Rg. 30, the update broadcast 
message, represented by reference numeral 132 in 
Rg. 30, is sent to all keystations logged on to tiie 
matching network 220 regardless of whetiier or not 
tiiey were involved in their particular matching 
transaction. It should be noted that preferably the 
first six steps illustrated in f=ig. 30 witti respect to 
the central matching computer 221 are all essen- 
tially asynchronous to any outside events. When 
ttie keystations 202 and 206 receive it\e update 



broadcast message, it will be processed against 
the local keystation book database 110. 112 and 
the local copy of the book will be maintained. As 
was previously mentioned, it should be rioted that 

5 this local keystation t)ook 110, 112 is not an exact ■ 
cart)on copy of the central system book 118, but 
rather is only a selected subset of it which com- 
prises an accumulated summary of bids and offers 
within tiie assigned display depth. Thus, preferably, 

10 Rg. 30 illustrates a generic template for the pro- 
cessing of messages throughout the integrated 
trading system 200 in accordance with Ihe method 
of the present invention in order to provide tiie 
distributed functionality of tfie system to keysta- 

75 tions logged on to the matching network 220. 

It should be noted that the concept of originat- 
ing keystation and counterparty keystation moves 
around with each transaction so that for each trans- 
action the originator may be different and may. for 

20 different transactions occurring at the same time, 
be an originating keystation in one instance and a 
counterparty keystation in another instance, in ad- 
dition, there are other instances in which the 
keystation may merely be a bystander and not 

25 invoh/ed in the particular transaction at all. Prefer- 
ably the control of the overall distributed matching 
system is maintained by ttie central matching host 
computer 224 which operates in accordance with a 
set of rules whteh govern how the transactions are 

30 processed. Preferably, the central matching host 
computer 224 processes transactions against a 
particular fading instrument in time order of entry 
into the system. In this regard it should be noted 
that it is not time entry of orders ^ se but time 

35 entry of orders related to a particular trading book 
or fading instrument Thus, there would be time 
order enfry assigned to Yen, a different time order 
entry consideration assigned to Deutsch Marks, 
and so forth if the trading instruments were foreign 

40 exchange currencies. 

In Rgs 31-34. which correspond to Rgs. 4^ 
and 8 of GB-A-2,224,141, tiie trading ticket output 
is shown. Pressign the TICKET key on the in- 
tegrated keyboard 240 causes the expanded analy- 

45 sis display mode to be entered or stored in ttie 
data base server 262. As was previously men- 
tioned, in this mode, tiie expanded analysis for the 
cunrent conversation, assuming the keystation is 
connected to the conversation communication net- 
so work 218, is displayed on the screen 238. The 
expanded analysis preferably shows the full con- 
tents of all the fields that can appear in the analysis 
except that payment instructions may, if necessary, 
be truncated. In the case of forward deals, prefer- 

55 ably the information for both value dates is shown, 
requiring four transactions. While in exparKled ana- 
lysis display mode, the expanded analysis on dis- 
play is preferably kept up-to-date with the con- 
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versation. Swapping between two conversations 
would automaticaiiy preferably swap between the 
two expanded anaiyses so that the one for the 
cunrent conversation was always visible. The ex- 
panded analysis display mode preferably remains 
in effect until a different use of this display area on 
the screen 238 is requested. Preferably, if a print- 
out of the conversation analysis is requested, the 
output on the conversation printer 230 is similar to 
that of the displayed window, atthough the payment 
instructions may be moved to a separate line if 
desired. With respect to printing a conversational 
ticket witii the ticket printer 226. the format of the 
ticket is preferably similar to tiie expanded analysis 
such as the conversational trading ticket illustrated 
in Rg. 17. however the order of the information 
may be changed to present the more critical in- 
fonmation first Of course, atthough the creation and 
storage of a ticket has been described in tenms of 
real time conversation analysis, such a system is 
not necessary for the generation of tickets per se 
which merely requires a local data base storage of 
trading tickets no matter how these trading tickets 
are dynamically created, with tiie data base server 
262 providing such a local data base storage, by 
way of example, in tiie integrated terminal control- 
ler 214. 216 for both conversational ti'ading tickets 
and match tickets, with the match tickets being 
stored as pseudo conversation, such as illustrated 
in Rg. 16. by way of example. 

For purposes of t^etter understanding tfm pre- 
ferred ticket output feed 234. 236, tiie prefenred 
ticket output protocol and process will now be 
described for handling the transfer of trading ticket 
information between the local data base server 262 
and the back office computer. In this regard, witti 
reference to U.S. Patent No. 4,745,569 incorpo- 
rated by reference herein, the local data base serv- 
er 262 is analogous to the kx:al data base de- 
scribed in tJ.S. Patent ^to. 4.746,559, except as 
will be described in greater detail hereinafter, with 
respect to the various differences as it relates to 
tiie presentiy preferred ticket output protocol and 
process employed in the system 200. Altfiough, the 
preferred ticket output protocol preferably em- 
ployed in the system 200 preferably employs field 
identifiers or ROs which are anak)gous to the fiekl 
identifiers refenred to in the aforementioned U.S. 
Patent 1^. 4,745.559. tiie information contained 
therein is totally different In place of the record 
identifier codes or RICs referred to in tiie afore- 
mentioned U.S. Patent No. 4.745.559. tiie ticket 
output protocol process preferably employs unique 
deal identifiers which conrespbnd to the ticket num- 
t»er on the printed deal ticket as well as to tiie 
integrated terminal controller 214.216 which con- 
tains tiie k)cal data base server 262 containing tiiat 
record. Thus, the deal or tirading ticket identifier 



includes the terminal controller identifier as well as 
a ticket number, with deals preferably being given 
sequential numbers in order of their confirmation. 
The sequence is preferably in the range of 1 - 

5 999999, by way of example, for each terminal 
controller 214,216. The deal identifier preferably 
starts with the tenminal controller Identifier and a # 
and is followed by the sequential number, such as, 
for example. AAAA#1 23456 for deal number 

10 123456 on terminal confroiler AAAA. In addition to 
retrieving ttie deal per se. the status of the data in 
tiie terminal controller system can also preferably 
be retrieved using the terminal controller identifier 
AAAA#INFO. by way of example. 

75 Preferably, as will be described in greater de- 
tail hereinafter, the data base server 262 can sup- 
ply two kinds of data to be retrieved atxsut tiie 
deals being conducted by tiie keystations asso- 
ciated witti tfiat terminal controller 214. 216; name- 

20 ly information on a deal, and status information on 
what is stored in the data base. As will be de- 
scribed in greater detail hereinafter, it is the up- 
dates from the status record which are preferably 
looked at to see if there is a change in status 

25 indicating that a new trade has arrived, which per- 
mits rapid transfer of trading information, such as 
tiie trading tickets, without tiie need for continuous 
polling of tiie various terminal controllers 214.216. 
It shoukJ be noted that each terminal controller 

30 214J216 keeps its own unique record o£ deals and 
has its own unique set of deal identifiers which are 
independent of the other terminal controllers 214. 
216 associated with the t^ack office computer, as- 
suming more than one terminal controller is assa- 
ys ciated tiierewrtii, since a portion of tiie record iden- 
tifier is tiie unique identification of tfie terminal 
controller 214, 216 itself. A data record associated 
witti a terminal controller identifier or TCID, is pref- 
erably a collection of data items with each data 

40 item being assigned a unique Reld Identifier Num- 
ber or FID. The presentiy preferred ticket output 
protocol employed in tiie system 200 in accor- 
dance with ttie method of tiie present invention 
preferably uses the FID number to Identify each 

46 data item within a message. Preferably, records in 
tiie system are grouped into classes, such as for a 
deposit deal, or a swap deal or a single deal, such 
as a spot or outright deal, with each class prefer- 
ably relating to a set of RDs called a Reld List 

50 The Reld List is analogous to a template except 
that it relates to the fomnat of the transmission of 
the data as opposed to tiie display per se, with the 
Reld List defining which collection~^ "data items 
will be received for that dass of record. This Rekj 

55 List is preferably contained in the record res(X)nse 
of the data base server 262 to ttie request of ttie 
back office computer for trading ticket infoonation. 
Since single deals such as spot or outright 
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deals; swap deals; and deposit deals have certain 
characteristics unique from each other, unique field 
identifiers nnust preferably be provided to distin- 
guish these types of deals in the preferred ticket 
output protocol. 

Preferably, requests for the status of the deal 
or trading ticket data base contained in the local 
data base server 262 of a particular terminal con- 
troller 214, 216 will provide information to the back 
office computer on the earliest and latest deal 
identifiers stored at the local data base server 262. 
with the date and time of the trading tickets. This 
information would permit the back office computer 
to determine the range of trading tickets available 
for retrieval. 

Preferably, all fields within the messages trans- 
mitted between the local data base server 262 and 
the back office computer contain ASCII characters 
which makes them suitable for display on a video 
terminal with little or no additional formatting, thus 
making this data feed ideal for quick implementa- 
tion in a data display system, such as via the 
integrated screen display 238. 

Rg. 31 diagrammatically illustrates the various 
portions of the trading ticket output system con* 
cemed with the presently prefenred trading ticket 
output protocol of the system 200. Thus, a conven- 
tional serial line handler provided by ftre operating 
system is emptoyed with, for convenience of ex- 
planation, the input and output being separately 
illustrated as the input handler 800 and the output 
handler 802. The input process 804 preferably ex- 
tracts input bytes from the serial line via the input 
handler 800 and places the: in an input buffer 806. 
The input buffer 806 perfonms the checks for input 
packets and checksums and can also set flags to 
ask the ticket output process 808 to generate tiie 
control characters ACKNOWLEDGE and NO AC- 
KNOWLEDGE at appropriate points in the output 
stream. The input process 804 also preferably de- 
tects tiiese control characters, such as ACKNOWL- 
EDGE and NO ACKNOWLEDGE, at the appropriate 
points in the input stream, with the occurrence of 
these control characters being tested for by the 
ticket output process 808 when it has sent a mes- 
sage. The ticket output process 808 is preferably 
scheduled regularly and has several independent 
tasks, the main ones of which are preferably taking 
confirmed bytes from the Input buffer 806 and 
placing them in a message buffer 810. scanning 
the message 810 to find the next complete mes- 
sage if available and. when found, checking tiie 
message. If the message is faulty, an appropriate 
enror response is sent to the output message buffer 
812. If, however, the message is valid, appropriate 
flags are set to request the required action. Prefer- 
ably, no furtiier messages are then handled by the 
ticket output process 808 until the action is com- 



plete. If a ticket or status report is requested by an 
input message, then the ticket output process 808 
preferably gathers tiie data from the ticket data 
base 814 and places rt in tiie defined format. 

5 determined by tiie Held List, in the output mes- 
sage buffer 812. When a message has been as- 
sembled in the output message buffer 812. the 
ticket output process 808 preferably adds tiie ap- 
propriate control bytes and transfers it to the output 

10 handler 802, passing as many characters as the 
output handler 802 can accept at a time until tiie 
whole message has been transfenred to the fc>ack 
office computer from the local data base server 
262. The ticket data-base process 814 is preferably 

IS modified to support updates of the status data in 
tiie ticket output protocol. The addition is prefer- 
ably required when tiie data base is modified by 
the addition of a new trading ticket or the removal 
of an old ticket In these cases, tiie ticket data base 

20 process 816 preferably sets a flag so that the 
update will be created by the ticket output process 
808, with the flag being cleared, as appropriate, by 
tiie ticket output process 808. The ticket data-base 
process 816 is preferably designed so that it adds 

25 a ticket to ttie end of tiie data base 814 and 
obtains space as necessary by removing the earii- 
est tickets from the beginning of the data base 814. 
Either of those changes alters the status of the data 
base 814 so that when there is a status check by 

30 the t>ack office computer, the back office computer 
is. thus, advised of the addition of a trading ticket 
by detecting the change in status. This is indicated 
to tiie ticket output process 808 by setting out a 
flag which is cleared, when appropriate, by the 

35 ticket output process 808. 

Rg. 32 further illustrates the presentiy pre- 
ferred operation of the ticket output process 808 
which, as can be seen, is entered at frequent 
intervals. The logic preferably gives priority to re- 

40 sponses to requests, and handles one request at a 
time. A request preferably remains in ttie input 
message and analysis stage 810 until it has been 
answered. When any message has been created 
for output preferably tiie ticket output process 808 

45 is dedicated to tiie output of the message until it 
has been ACKNOWLEDGED or has been transmit- 
ted a given number of times without acknowledg- 
ment Preferably, when no message is being out- 
put, tiie ticket output process 808 checks to see if 

50 an input message has requested a trading ticket Is 
so. the trading ticket is retrieved, a message is 
created according to tiie type of ticket by use of 
ttie Reld List, and the new message Is marked for 
output to tiie back offrce computer. When no ticket 

56 is being requested, the ticket output process 808 
preferably checks if tiie status record has been 
requested. If so. the status data is preferably ob- 
tained and tiie status record is set up for output in 
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a similar way to the trading ticket output. If. how- 
ever, no status is requested, then the ticket output 
process 808 preferably checks to see if the status 
has been marked as changed by the ticket data 
base process 816. If a change is detected, the flag 
indicating the change is preferably cleared. The 
logic then preferably checks if the status record is 
cunrentty requested in an updating mode. If this 
has occurred, the new status is preferably output 
on the line and the ticket output process 808 cre- 
ates a new status in the output message buffer 812 
and then anranges that it will output the message. 
In the aforementioned implementation, the status 
record is preferably updated by retransmission of 
the whole status record. If none of the above corh 
ditions exist the ticket output process 808 then 
preferably tries to find a complete new Input mes- 
sage. If this succeeds, the ticket output process 
808 preferably analyzes the Input message. A valid 
message causes a change in the analysis data 
The analysis of a valid message requesting data 
sets flags which then cause the ticket output pro- 
cess 808 to generate the requested output as it is 
rescheduled repeatedly. Other valid messages just 
change the cunrent state of the analysis data, 
whereas invalid messages cause the ticket output 
process 808 to generate an appropriate en^or re- 
sponse. The atx}ve described procedure is illus- 
trated in the flow diagram of Rg. 32. 

Refem'ng now to Rg. 33 the operation of the 
terminal controller data base server 262 when a 
new trading ticket has b»een generated is shown. 
Thus, when a new deal Is generated, as repre- 
sented by reference numeral 850. the trading ticket 
corresponding to the deal is added to the list of 
deals, with allocations of the deals or tickets being 
in numerical order as was previously described, 
such as represented by reference numeral 852. 
The status record is then updated, giving the last 
deal number, as represented by reference numeral 
854, and a determination is made as to whetfier the 
deal status is being retrieved with an update, as 
represented by reference numeral 856. If the deal 
status is being retrieved with an update, the update 
is sent to the back office computer to update the 
status record, such as represented by reference 
numeral 858. and if it is not then the routine ends, 
as represented by reference numeral 860. 

Referring now to Rg. 34, a fk>w chart is shown 
of tfie operation of the local data base server 262, 
witii respect to requests for tickets received by the 
local data base server 262 from the back office 
computer. Thus, the trading ticket requested by the 
t>ack office computer is requested by Deal Iden- 
tifier, which, as previously mentioned, does not 
specify the type of deal. This is represented by 
reference numeral 900. The type of deal indicated 
is tiien looked at in tfie ticket record being re- 



trieved, as represented by reference numeral 902, 
and the ticket output message is then formatted 
using the Reld List specific to the type of deal, as 
represented by reference numeral 904 in Rg. 34. 

5 The formatted record response message, which 
now contains infonmation as to the type of deal, as 
well as the various parameters and values asso- 
ciated with them, is tiien sent to the back office 
computer in the appropriate deal fonmat. based on 

10 the Rekj List contained in tiie retrieved record and, 
for the first time, the back office computer finds out 
what type of deal was involved with the request. 
This is represented by reference numeral 906. It 
shouki be noted, as previously mentioned, the re- 

75 quest by the back office computer and the re- 
sponse to the back office computer from the local 
datatjase server 262. contain a "Tag" which Iden- 
tifies the particular request being made. 

Thus, by emptoying the integrated trading 

20 method of the present invention, the speed and 
reliability of both automatic matching and negoti- 
ated video conversational trades may be combined 
in a single system to provide individual subscnbers 
with maximum flexibiltty and optimal efficiency to 

25 effectuate and complete the type of trade demand- 
ed by the time and circumstances available, and to 
generate a ticket corresponding to the trade, ir- 
respective of ttie type of trade transacted. 

In the first aspect of tiie invention as defined 

30 by Claim 1. the system may further comprise a 
second interface means connectably disposed be- 
tween at least one of said keystation means in sakJ 
second plurality of keystation means and said first 
communication means for selectively interfacing 

35 said one of said keystation means in said second 
plurality of keystation means with said first commu- 
nication means, said one of said keystation means 
in said second plurality of keystation means com- 
prising video display means capable of displaying 

40 btoth said bids and said offers. The common data 
input means may further comprise means for tog- 
gling between said matching trades and said video 
conversational negotiated trades for selectively ef- 
fectuating said trades via said one of said keysta- 

45 tion means in said second plurality of keystation 
means. On of the keystation means in said second 
plurality of keystation means further comprises 
means for selectively varying the content of the 
display on said common video display means in 

50 response to said toggling of said data input means. 

In the first aspect of the invention as set out in 
Claim 1, the keystation means may comprise a 
computer means. Whether it does or not the inter- 
face means may comprise a conversation server 

55 means for interfacing said video conversational tex- 
tual data messages with said first communication 
means. Whether it does or not. ttie interface means 
may comprise a concentrator computer means for 

22 
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interfacing said bids and said offers with said first 
communication means. When the keystation means 
does comprise a computer means, the data input 
means may further comprise means for periodically 
providing a keep alive signal to said keystation 
computer means, said keystation computer means 
comprising means responsive to said periodically 
provided keep alive signal for deleting said selec- 
tively provided bids and offers selectively provided 
from said keystation means associated with a given 
data input means when said keep alive signal pe- 
riodically provided from said associated data input 
means is not provided. The means responsive to 
said periodically provided keep alive signal may 
comprise means for automatically terminating con- 
tact with all other keystation means in said system 
for a given keystation means associated with said 
given data input means when said keep alive signal 
periodically provided from said associated given 
data input means Is not provided. 

In tine first aspect of tfie invention as set out in 
Claim 1. the interface means may comprise a 
uniquely identifiable k)cal data base for Initially 
collecting trading ticket information relating to botii 
said automatically matched trades for said trading 
instruments and video conversational negotiated 
trades for said trading instruments, and means for 
communicating said collected trading ticket infor- 
mation to a remote t^ack office data base; whereby 
a common ticket generation scheme may be em- 
ployed in said integrated trading system for said 
trading instruments irrespective of tiie type of 
trade. The interface means may further comprise 
and integrated terminal controller means connec- 
tably disposed between said keystation means, 
said first communication means, and said uniquely 
identifiable k)cal data base for selectively interfac- 
ing said keystation means with said first commu- 
nication means. Altematively. tfie interface means 
may further comprise means for initially collecting 
said trading ticket information conresponding to 
said trades as self-K^ontained integral trading ticket 
records and storing said self-contained integral 
records at said uniquely identifiable local data 
base. The collecting and storing means may further 
comprise means for storing said self-contained in- 
tegral records at said uniquely identfflable local 
data base unique identification and a sequential 
numljer conresponding to the order of confinmation 
of each of said trades at said bcai data base. The 
sequential numbers may be independent of tiie 
type of trade conducted tiirough said integrated 
system. The system may further comprise means 
for retrievably requesting trading tickets from said 
local data base for providing said trading tickets to 
said remote t>ack office data base independent of 
tiie type of trade involved. 

In the first aspect of the invention as set out in 



Claim 1, the system my further comprise a host 
computer means for maintaining a host book data 
base comprising all of the active l>ids and offers 
associated with said matching transactions in ttie 

5 system by trading instrument, at least one of said 
first plurality of keystation means comprising a 
transaction originating keystation means for provid- 
ing a bid on a given trading instrument to said 
system for providing a potential matching t^ansac- 

10 tion and at least one of said second plurality of 
keystation means comprising a counterparty 
keystation means for providing an offer on said 
given ti'ading instiument involved in said potential 
matching transaction, said first communication 

IS means interconnecting said host computer means, 
said transaction originating keystation means and 
said counterparty keystation means in said inte- 
grated system for enabling data commnication 
ttierebetween for effectuating said automatically 

20 provided matching transactions. The host computer 
means may comprise means for processing said 
matching transaction for a given trading instrument 
in time order entry to said system. Altematively, 
both said transaction originating keystation means 

25 and said counterparty keystation means for said 
potential matching transaction may each have an 
associated local data base keystation book com- 
prising a subset of said host book. The keystation 
means associated with said potential matching 

30 transaction may comprise means for displaying 
said associated keystation book on video display 
means. Altematively. the content of each of said 
keystation books may have an associated display 
depth range controllable by said host computer 

35 means and being updatable by transaction update 
Ijroadcast messages received from said host com- 
puter means through said first communication 
means. The transaction originating keystation 
means and said counterparty keystation means 

40 comprise means responsive to said received trans- 
action update broadcast messages for updating 
said associated keystation books and means for 
providing directed messages to said host computer 
means corresponding to said bid and offer, respec- 

45 tively. said direct messages updating said host 
Ijook. The host computer means may comprise 
means for conditionally providing said transaction 
broadcast update meassages to said keystation 
means associated therevrith in response to the 

50 presence of an update condition, said update con- 
dition comprising updating of said host book and 
said received bid or offers within said host t)ook 
having a relative value compared with other bids or 
offers within said host book which is witfiin said 

55 keystation book display depth range of relative 
values; whereby controllable subsets of a dis- 
tributable system trading book may be selectively 
provided to ti'ading keystations in said integrated 
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system from the host for controllably masking the 
available trading market for said automatically 
matched trades. 

In the first aspect of the invention as set out in 
Claim 1, the data input means may further com- 
prise means for periodically providing a keep alive 
signal to said interface means, said interface 
means comprising means responsive to said pe- 
riodically provided keep alive signal for automati- 
cally terminating contact with all other keystation 
means in said system for a given keystation means 
associated with said given data input means when 
said keep alive signal periodically provided from 
said associated given data input means Is not 
provided. 

In the second aspect of tiie invention as set out 
in Claim 8. the common data input means may 
further comprise means for toggling between said 
matching trades and said video conversational ne- 
gotiated trades for selectively effectuating said 
trades via said first keystation means. The first 
keystation means may further comprise means for 
selectively varying the content of the display on 
said common video display means in response to 
said toggling of said data input means. The means 
for selectively varying the display content of said 
common video display means may comprise 
means for varying the format of said display on 
said comnrK>n video display means in response to 
said toggling of said data Input means. 

In the second aspect of tiie invention as set out 
in Claim 8. tiie system may further comprise a 
second integrated temninal contoriler means con- 
nectably disposed between at least a second 
keystation means and said data communication 
network for selectivety interfacing said second 
keystation means with sakt data communication 
network, said second keystation means comprising 
a common video display means capable of display- 
ing both said bids and said offers assodated with 
said matching transactions and said video con- 
versational textual data messages assodated witf) 
said negotiated trades, and a common data input 
means for selectivety inputting both said video con- 
versational textual data messages to said data 
commnication network through said second inte- 
grated tenminal controller means for effectuating 
said video conversational negotiated trades and 
said bids and said offers to said data commnication 
network through said second integrated terminal 
controller means for effectuating said automatically 
provided matching transactions. 

In the second aspect of tiie invention as set out 
in Claim 8, the integrated temiinal controller means 
may comprise a concentrator computer means for 
interfacing said bids and said offers with said data 
communication network. Altematively, it may com- 
prise a conversation server means for interfacing 



said video conversational textual data messages 
with said data communication networic. In this case, 
ttie conversation server means may furttier com- 
prise common data base means for integrating 
5 trade data relating to botii said bids and said offers 
and said video conversational textual data mes- 
sages. Altematively, the integrated terminal control- 
ler means may further comprise a concentrator 
computer means for interfacing said bids and said 

10 offers with said data communication network. The 
integrated tenminai controller means may further 
comprise a kx^ai area network means for tieing said 
conversation server means and said concentrator 
computer means together. The first keystation 

15 means may comprise a terminal computer means, 
said terminal computer means being tied to said 
local area network means. 

In tiie second aspect of the invention as set out 
in Claim 8, the first keystation means may com- 

20 prise a computer means. The data input means 
may furtiier comprise means for periodically pro- 
viding a keep alive signal to said first keystation 
computer means, said first keystation computer 
comprising means responsive to said periodically 

25 provided keep alive signal for deleting said selec- 
tively provided bids and offers selectively provided 
from said first keystation means associated with 
said data input means when said keep alive signal 
periodically provided from sakl data input means is 

30 not provkJed. The means responsive to said pe- 
riodically provided keep alive signal comprises 
means for automatically terminating contact with all 
other keystation means in said system for said first 
keystation means assodated with said given data 

35 input means when said keep alive signal periodi- 
cally provided from saki assodated data input 
means is not provided. 

In the second aspect of the Invention as set out 
in Claim 8. the integrated terminal controller means 

40 may comprise a uniquely identifiable local data 
base for initially collecting trading ticket information 
relating to both said automatically matched trades 
for said trading instruments and video conversa- 
tional negotiated trades for said trading instru- 

45 ments, and means for communicating said col- 
lected trading ticket information to a remote back 
office data base; whereby a common ticket genera- 
tion scheme may be empkjyed in said integrated 
trading system for said trading instruments ir- 

50 respective of tiie type of ti-ade. The integrated 
terminal controller means may further comprise 
means for initially collecting said trading ticket in- 
fonmation corresponding to said trades as self- 
contained integral trading ticket records and storing 

55 said self-contained integral records at said uniquely 
identifiable local data base. Altematively, the in- 
tegrated terminal conti'oller means may comprise a 
conversatipn server means for interfadng said vid- 
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eo conversatonai textual data messages with said 
communication network. The conversation server 
means may comprise means for communicating 
said collected trading ticket infonnnation to said 
remote back office data base. s 

In the second aspect of the invention as set out 
in Claim 8, at least said first keystation means may 
further comprise pointer means for locating data 
display areas in a windowed textual video display 
on said video display means, and storage means io 
for retrlevably storing a plurality of unique keysta- 
tion contact signals capable of initiating conversa- 
tion contact with at least one of said other keysta- 
tion means through said data communication net- 
work, each of said other keystation means having a is 
unique associated identification code, said keysta- 
tion contact signals corresponding to said unique 
associated identification codes, said windowed tex- 
tual video display comprising a windowed display 
of at least one of said unique associated idere 20 
ficiation codes, said pointer means comprising 
means capable of locating said windowed display 
of said unique associated identification code in said 
windowed textual video display and providing a 
conversational contact message signal to said 25 
keystation storage means in response thereto for 
retrieving said unique keystation contact signal cor- 
responding to said kx:ated unique associated iden- 
tification code for providing a calling signal to said 
corresponding keystation means through said data 30 
commnication network. The pointer means may 
comprise a mouse. 

In the second aspect of the invention as set out 
in Claim 8, the system may further comprise inter- 
face means comprising said Integrated terminal 35 
controller means and a uniquely identifiable local 
data base for initially collecting trading ticket in- 
formation relating to both said automatically 
matched trades for said trading instruments and 
video conversational negotiated trades for said 40 
trading instmments, and means for communicating 
said collected trading ticket information to a remote 
back office data base, whereby a common ticket 
generation scheme may be employed in said in- 
tegrated trading system for said trading instru- 45 
ments inrespective to the type of trade. 

In tiie second aspect of the invention as set out 
in Claim 8. ttie system may further comprise a host 
computer means for maintaing a host book data 
base comprising all of the active bids and offers so 
associated with said matching transactions in tiie 
system by trading instrument, at least said first 
keystation means comprising a transaction originat- 
ing keystation means for providing a bid on a given 
trading instrument to said system for providing a S6 
potential matching transaction and at least on of 
said other keystation means comprising a counter- 
party keystation means for providing an offer on 



said given trading instrument involved in said po- 
tential matching transaction, said data communica- 
tion network interconnecting said host computer 
means, said transaction originating keystation 
means and said counterparty keystation means in 
said integrated system for enabling data comm- 
nication therebetween for effectuating said auto- 
matically provided matching transaction. Botti said 
transaction originating keystation means for said 
potential matching transaction each have an asso- 
ciated kxat data base keystation book comprising 
a subset of said host t>ook. Altematively or in 
addition, botii said transaction originating keysta- 
tion means and said counterparty keystation means 
for said potential matching transaction each have 
an associated local data base keystation book com- 
prising a subset of said host ix>ok. 

In tfie second aspect of the invention as set out 
in Claim 8, the data input means may further 
comprise means for periodically providing a keep 
alive signal to said integrated terminal controller 
means, said integrated terminal controller means 
comprising means responsive to said periodically 
provided keep alive signal for automatically termi- 
nating contact with all other keystation means in 
said system for said first keystation means asso- 
ciated with said data input means when said keep 
alive signal periodically provkled from said asso- 
ciated data input means is not provided. 

In the third aspect of the invention as set out in 
Claim 9. the method may further comprise tiie step 
of sharing the use of said data input means at said 
given keystation means for inputting said bids and 
said offers associated with said matching transac- 
tions and said video conversational textual data 
messages associated with said video conversar 
tional negotiated trades. Whether it does or not the 
method may further comprise a step of integrating 
initial access to tx>th said matching trades and said 
video conversational negotiated trades in said sep- 
arate networks. Separate networits may be for the 
given keystation means for enabling the given 
keystation means selectively to effect both said 
automatic matching trades and said video coo- 
versational negotiated trades tiirough said separate 
networks. 

In the third aspect of the invention as set out in 
Claim 9. ttie metiiod may further comprise a step 
of sharing tiie use of said data input means for a 
given keystation means for selectively providing 
transactional data wttfi respect to both said auto- 
matic matching trades and said video conversa- 
tional negotiated trades to said system. In the third 
or fourth aspects of the invention as set out in 
Claims 9 and 10 respectively, the method may 
furtiier comprise a step of retrievably storing com- 
pleted trades from both said automatic matching 
trades and said video conversational negotiated 
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tracfes together. 

In ttie fourth aspect of the invention as set out 
in Claim 10, the method may further comprise a 
step of commonly collecting trading ticket informa- 
tion relating to both said automatically matched s 
trades for trading instruments traded through said 
first data communication network and said video 
conversationat negotiated trades for trading instru- 
ments traded tiirough said second data commu- 
nication network. There may be a further step of io 
communication said commonly collected trading 
ticket information to a remote back office data base 
irrespective of the type of trade effectuated tiirough 
said integrated tenminal controller. Said commu- 
nicating step n^y furtiier cpmprise the step of 75 
communicating said collected trading ticket infor- 
mation as self-contained integral trading ticket 
records. 

In the fourtti aspect of the invention as set out 
in Claim 10. the method may fruther comprise tt>e 20 
steps of maintaining a host book data base com- 
prising tiie active bids and offers associated with 
said matching transactions by trading instrument, 
and interfacing said given keystation means with 
said host book data base through said integrated 25 
terminal controller for effectuating said automati- 
cally provided matching transactions. Whether it 
does or not. the method may further comprise the 
step of processing said matching transactions for a 
given trading instrument in time order entry to sakj so 
first data commnication network, when it does com- 
prise tiie step of maintaining a host book data 
base, it may further comprise a step of locally 
storing a subset of sakt host book data base at 
said given keystation means associated with sakJ 36 
potential matching transactions. It may then com- 
prise a step of providing transaction update broad- 
cast messages to said gh^ keystation means 
through said first data communication networit and 
said integrated terminal controller for updating sakJ 40 
locally stored subsets In accordance with sakt 
transactional data refating to said automatic match- 
ing transactions. The transaction update broadcast 
message providing step may furtiier comprise the 
step of selectively providing said update messages 46 
in response to a predetermined condition. The up- 
date message selective providing step may com- 
prise the step of controllably masking the available 
trading market for said automatically matched 
trades at said given keystation means. so 

fn the fourth aspect of the invention as set out 
in Claim 10, the given keystation means may com- 
prise computer means, said method further com- 
prising the step of periodically providing a keep 
alive signal from said given keystation data input ss 
means to said given keystation computer means, 
and deleting said bids and offers provided from 
said given keystation means when said keep alive 



signal is not periodically provided from said gwen 
keystation data input means. The mettiod may tiien 
further comprise a step automatically terminating 
contact witii all other keystation means in said 
system for said given keystation means when said 
keep alive signal Is not periodically provided from 
said given keystation data input means. 

Claims 

1 . An integrated trading system capable of provid- 
ing both automatic matching trades for trading in- 
struments between potential counterparties at dif- 
fererrt locations and video conversational negoti- 
ated trades for trading instruments between poten- 
tial counterparties at different locations over a first 
communication means, said automatic matching 
trades comprising trades in. which bids from poten- 
tial counterparties are automatically matched 
against offers from potential counterparties for giv- 
en trading instruments for automatically provkjing 
matching transactions in order to complete said 
automatic matching trades for said given instru- 
ments, sakl video conversational negotiated trades 
comprising trades in which video conversational 
textual data messages are selectively routed be- 
tween potential counterparties with respect to bids 
and offers for given trading Instruments for en- 
abling discretionary conversational messages to be 
exchanged between said potential counterparties in 
order to negotiably completed said vtoleo conversa- 
tional negotiated trades, said integrated trading 
system comprising a first plurality of keystation 
means; and a second conununication means, said 
first plurality of keystation means being selectively 
connectable to said first communication means 
through said second communication means for ef>- 
abling said first plurality of keystation means to 
selectively communk:ata with a second plurality of 
keystation means at said different kx:ations to ef- 
fectuate said matching trades and said video con- 
versational negotiated trades, at least a first one of 
sakj keystation means in said first plurality being 
capable of effectuating at least said automatic 
matching trades and at least a second one of saki 
keystation means in saki first plurality being ca- 
pable of effectuating at least said video conversa- 
tional negotiated trades, said first one of said 
keystation means in said first plurality comprising 
video display means capable of displaying at least 
said bids and said offers associated with said 
matching transactions and a data input means for 
selectively inputting saki bids and said offers to 
said first communication means through said sec- 
ond communk:ation means for effectuating sakJ 
automatically provided matching transactions, saki 
second one of said keystation means in said first 
plurality comprising video display means capable 
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of displaying said video conversational textual data 
messages associated with said negotiated trades 
and a data input means for selectively inputting 
said video conversational textual data messages to 
said first communication means through said sec- 
ond communication means for effectuating said 
video conversational negotiated trades, said second 
communication means comprising interface means 
connectably disposed between said first one of 
said keystation means in said first plurality and 
said first communication means and said second 
one of said keystation means in saki first plurality 
and said first communication means for selectively 
interfacing said first one of said keystation means 
in said first plurality and said second one of said 
keystation means In said first plurality with said 
keystation means in said second plurality through 
said interface means and said first communication 
means; whereby both automatically matched trades 
for said trading instruments and video conversa- 
tional negotiated trades for said trading instruments 
may be conducted through said integrated trading 
system. 

2. An integrated trading system in accordance with 
claim 1 wherein said first communication means 
comprises separate communication paths for said 
matching trades and said video conversational ne- 
gotiated trades. 

3. An integrated fading system in accordance with 
claim 1 wherein said second communication means 
comprises a common communication path for said 
matching trades and said video conversational ne- 
gotiated trades. 

4. An integrated trading system in accordance with 
claim 3 wherein said second communication means 
common communication path comprises a local 
area network means. 

5. An integrated trading system in accordance with 
claim 1 wherein at least said video display means 
for said first one of said keystation means in said 
first plurality further comprises means capable of 
displaying said video conversational textual data 
messages associated with said negotiated trades 
for effectuating said matching trades. 

6. An integrated trading system in accordance with 
claim 5 wherein said first communication means 
comprises separate communication paths for said 
matching trades and said video conversational ne- 
gotiated tildes. 

7. An integrated trading system in accordance with 
claim 5 wherein at least said data input means for 
said first one of said keystation means in said first 
plurality comprises a common data input means for 
selectively inputting both said video conversational 
textual data messages to sakJ first communication 
means through said second communication means 
for effectuating said video conversational negoti- 
ated trades and said t>ids and said offers to said 



first communication means through said second 
communication means for effectuating said auto- 
matically provided matching transactions. 

8. An Integrated trading system capable of selec- 
5 tively providing both automatic matching trades for 

trading instruments between potential counterpar- 
ties and video conversational negotiated ti'ades for 
trading instruments fc)etween potential counterpar- 
ties over a data communication network, said auto- 

70 matic matching trades comprising trades in which 
bids from potential counterparties are automatically 
matched against offers from potential counterpar- 
ties for given trading instruments for automatically 
providing matching transactions in order to com- 

75 plete said automatic matching trades for said given 
instruments, said video conversational negotiated 
trades comprising trades in which video conversa- 
tional textual data messages are selectively routed 
between potential counterparties with respect to 

20 bids and offers for given trading instruments for 
enabling discretionary conversational messages to 
be exchanged between said potential counterpar- 
ties in order to negotiabty complete said video 
conversational negotiated trades, said integrated 

25 trading system comprisir>g at least a first keystation 
means selectively connectable to a plurality of oth- 
er keystation means through said data communica- 
tion network for enabling said first keystation 
means to selectively communicate with sakl other 

30 keystation means to effectuate said matching 
trades and said video conversational negotiated 
tildes; and integrated terminal controller means 
connectably disposed between said first keystation 
means and said data communication network for 

35 selectively interfadng said first keystation means 
with said data communication network, said first 
keystation means comprising a common video dis- 
play means capable of displaying both said bids 
and said offers associated with said matchir^g 

40 transactions and said video conversational textual 
data messages associated with said negotiated 
trades, and a common data input means for selec- 
tively inputting both said video conversational tex- 
tual data messages to said data communication 

45 network through said integrated tenminal controller 
means for effectuating said video conversational 
negotiated trades and said bids and said offers to 
said data communication networic through said ir>- 
tegrated terminal controller means for effectuating 

50 said automatically provided matching transactions; 
whereby both automatically provided matched 
trades for said trading instruments and video con- 
versattonal negotiated trades for said trading instru- 
ments may be selectively conducted over said 

55 integrated trading system. 

9. An integrated ti-ading system method for provid- 
ing both automatic matching trades for trading in- 
struments between potential counterparties and 
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video conversational negotiated trades for trading 
instruments between potential counterparties over 
separate networks relating to said automatic match- 
ing trades and said video conversationat negotiated 
trades, each of said networlo comprising a plurality s 
of keystation means selectively connectable to 
each other- tiirough said separate network, said 
keystation means comprising data input means and 
video display means; said method comprising the 
steps of sharing use of said video display means io 
for a given keystation mear^ for enabling said 
given keystation means to transact t)Oth said auto- 
matic matching trades, in which bids from potential 
counterparties are automatically matched against 
offers from potential counterparties for given trad- is 
ing instruments for automatically providing match- 
ing transactions in order to complete said auto- 
matic matching trades for said given trading instru- 
ments, and said video conversational negotiated 
trades, in which video conversational textual data 20 
messages are selectively routed between potential 
counterparties with respect to bids and offers for 
given trading instruments for exchanging discre- 
tionary conversational messages between said po- 
tential counterparties for negotiably completing said 25 
video conversational negotiated trades; and selec- 
tively interfacing said given keystation means with 
botii of said separate networks for selectively con- 
necting said given keystation means to keystation 
means in both of said separate networks for en- 30 
abling said given keystation means to selectively 
transact both said automatic matching trades and 
said video conversational negotiated trades through 
said separate networics; whereby both said auto- 
matically provided matchir^ trades and said video 35 
conversational negotiated trades may be conducted 
at said given keystation means for tiading desired 
trading instruments irrespective of the type of 
trade. 

10. An integrated trading system method for pro- 4q 
viding both automatic matching trades for trading 
instruments between potential counterparties over a 
first data communication network to a plurality of 
keystation means selectively connectable to each 
other through said first data communication net- 45 
work and video conversational negotiated trades for 
trading instruments between potential counterpar- 
ties over a second data communication network to 
a plurality of keystation means selectively connec- 
table to each other through said second data com- so 
munication network, said keystation means com- 
prising data input means and video display means, 
said keystation means being selectively connec- 
table to both said first and second data commu- 
nication networks through interface means for so- ss 
lectively interfadng said keystation means with 
each other through said first and second data com- 
munication networks, said method comprising the 



step of providing transactional data between said 
keystation means and said potential counterparties 
relating to both said automatic matching transac- 
tions and said video conversational negotiated 
trades through a common integrated terminal con- 
troller means for enabling a gh/en keystation means 
to selectively effectuate both said automatic match- 
ing transactions and said video conversational ne- 
gotiated frades through said common irrtegrated 
terminal controller to said first and second data 
communication networks, respectively. 



28 



EP 0 434 224 A2 



APPENDIX 
TABLE A 



• Include <stdlo.h> 
•includi <und«f.h> 
«unO€f HOkChhGR 
•undsf NOVIHHESSAGES 
tinclud« <windaws.h> 

• includ« 'aJaag.n' 
ttnclude "aictrl.h" 
•Include "dartif.h' 
•Includ* 'dUtogid.h' 

■ •Include "okt^^logn-n" 
•Include *fdt3_dU,h" 
•Include "rdis'cll.h" 
•Include ''i3netLib.h' 
•Include 'fatal, h* 



typedef enua 

{ 

DART, 
ROTS 

) applicatioh: 



typedef enun 

{ 

S^OUERYSEMT, 
S^OueRVWAlT, 

s'logoffsent . 
s'logoffwait, 
s'loggeoofp. 



I • 1 setc a AOISJOUERYLOGOFF and » waiting for a reply •/ 
/« nave 90 1 a RcIs_0LRCSONSE and waiting for ot^er •/ 
/• hase se«c a ROIS^LOGOFF to both parties ■/ 
/■ wa*itf-9 for the other partie to reply •/ 
/• bot- carties are logged off •/ 



s dartioggihgon, 
s'rotsloggingon. 

s'OARTACTlve, 
S^IKHIBITEO, 
s'iNACTIVE 
) ROI STATES: 



/• %.a't -5 for DART to logon •/ 

.a*: -3 fo*" ROTS to logon •/ 
*• Dct" sa't'es are logged on and active */ 

oa'i IS active •/ 

/• •'».**it*si inhibited •/ 

^j: : -a-Ei»*9 for dialog data •/ 



/• ROI states «/ 

ROI STATES state » S 



/■ used for debugging •/ 
•If defined lOEBUG) 

Char tpState (] s ("S^OuE^vssm: . S^auERYWAlT". 'S^tOGOf FSEMT" . "S lOGOFFWAlT". *S_tOGGE0OFf " , -S.OARTLOGGINOOH 
-s'ROTS;.OGCrN3Ci«-7 S^ACTIVE". *S_DARTACTIV£- . -S^INMIBITED". 'S^IMACTIVE") ; 

•endif 

/• debug macros •/ 
•define L(r(s) is 
•define LlTERALCn) LlT{n} 

•define whERE _'^I*.£_ • I ME_) "): 



static HUNO hMndOialog s NwL*.. 

static LOGOM^OATA LogonOata « -:o> . (3) .(0). (0}.{0)); 

static long Logoff Reason « 3. 

/• fltajiinu« It-Qit if rO's 
•define HAx^OARTto s;: 
•define max^WTSIO .:23 

/• Id's senr out to apps «/ 
static mORO Oartld ^ 0; 
static UORO Rdtsld 3 O; 



static votd \.0CAL SetRO:S:a:ft «n^:_£*A*ES s); 
static void lOCAt TellROTSLogon :.="g ^»*ram} 
static void EndlooonOialog (voie;. 
static WORD lOCAl c;etNewId (APOtlC^VCw 4pp) . 
static void LOCAL SendLogeff (lof) ;4«asoA). 



/t««t«««.«««t«.*«*.. ««•*>. •••.••.••••t.f»«.....t*. »•••«• 

/• Hodule : rdllogon.c 

/• Routine: void LOCAL CitLogOata I^anD-.e hHe«) 

/« this procedure is seit tre logon data from setup ano then 

/• starts the l09on process w^th OART and ROTS 
/• Return : 
/• 
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void LOCAL 01«log&aU (HANtM.E hM«m} 
( 

LPLOGON.QATA Ip > (LPLOGON^MTA) GUb«tlock (hMon); 
LogonOaU * tip; 
GLobatUMock (M4mi); 

/• long p«r«Det«r is Handle:of fsic, 1 an not going co ^eeo »n offset 

• at tt^« laonent so offset is zero 
•/ 

/• SftC ft«9 to t«lL tnyMif that reply b* from OART «s trie oart 

• logs on beforo ROTS 
•/ 

SatftOtSUta (S.OAflTLOGGtNGON) ; 

/• dwelt ratult fro* logon messaga «/ 

switch ((WORD) CtnStndHessaga (hoO OaRT. ROIS LOGON. 0. hakelCnG (0. ri<em))) 
< 

/• Can't log on bacauM printers nava failed •/ 
* casa LO.miNTCRSFAiLEO: 

SatROXSUta (S.LOGGEOOfF) ; 

CtrlSandHessaga (hOO SCTuP. Oh ERftORTEXTOULOG, hwnoOtalog. (long) TC PRINTERS rAlLEO); 
break; 

/• Can't log on since ROTS ts oresent and 

• tha ROTS trade printer is not installed •/ 
case LO.PRINTERNOTtNSTALLEO: 

SetROXStata (S_LOG6E0OFF} ; 

CtrlSendHessage {HOO.SETuP. OK ERRORTEXTDIALOG. bWndOialog. (long) TC NO ROTS PRINTER); 
break; 

case LO^OK: 
break; 



case LO^BAOOATA: 

OartFatalExIt (FTL BAO 
break; 



OATA): 



cas* LO.ALREAOVON: 

OartFatalExit (FTL alREa> Cn}; 
braak; 

default: 

OartFatalExit (FTL BAO R£Pl.v; . 
break: 

) 



/• Nodule : rdi logon. c -/ 

/• Routine: void LOCAL OUlogr«aryjle (*'tfNO nwr^) •/ 

/• seta the handle to fe dialog disotayed by ^ezuo, ims '^a-*s;e «/ 

/* Is than used to pass s^essages to me dialog, *e e"3r fnessa^es >' 

/• Return : void •/ 

/• •/ 



void LOCAL OUloghandle (hwno r^-o; 



{ 



hWndOlalog = hWnd; 



/• Nodule : rdllogon.c •/ 

/• Routine: static void EndLogorC*a;og (void) «/ 

/• sends a nessaga to t^e setup (oodwle to end t^e icgon dialog •/ 

/• •/ 

/• Return : void «/ 

/• - •/ 



static void EndLpgonOlalog ^void) 



{ 



CtrlSandMessag« IMOO^SCTUP. OM^SsrilKOG. -•'^Oialog. OL); 



/• Nodule : rdllogon.c 

/• Routine: sUtIc MORO LOCAL GetNe^Id (APPLiCiTION App) 

/• el locates a new id for ROtS or dart 

/• 
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/• deturn : n«w id 



static WOftO LOCAL C«CM«w(d ( APPLICATtOM App) 

static WORO OartIO « 0; 

static WORD ROrsiO = MAX^OARTIO * 1; 

Switch (Apg) 

{ ■ 

case OART: 

/• incrwwot countar and check for roll ov«r •/ 
3*ctID*^; 

»f (OartID >» MAX^OARTIO) 

OartIO « 0; 
• If defined (OCBUG) 

printf("Oart Id « XdXn*, OartIO); 
«end1f 

return OartIO; 
case ROTS: 

/• increovnt counter and check for roll over •/ 
ROTSIOf-f; 

If (ROTSIO >3 HAX^ROTSXO) 

ROTSIO = MAX OARTIO ♦ i: 
■If defined (OEOm) 

prIntfCROTS ^tf s Xd\n". ROTSIO); 
<endif 

return ROTSIO; 

aef ault: 

(^atalExit {FfLjHCORRBCJ 4PP); 
break; 

) 

) 



/> Kodule : 
/" Routine: 
/• 
/• 

/• Return : 
/• 



rdi logon. c 

void LOCAL Key Soar^rat ached (void) 

called when the kevooard 1» detached, and then takes action 

according to ROI so«c 

void 



•/ 
•/ 
•/ 
•/ 
•/ 



void LOCAL XeyaoardOetached (void) 



• If defined (OEBUS) 

pr t ntf ( - OM_K800ETACH\n- ) ; 
■endif 



switch (state) 
( 

case S.IKACTIVE: 
case s'OARTACTivE: 
case s\OG{>£00FP: 
case S^OUERYSCKT: 
case s'ouEftVWAlT: 
case s'LOGOFfSCNT: 
case s\0C0FfWAlT: 
case s'aCTIvE: 
case s'oaRTlO(WIkG0h: 
case S.ROTSLOGGZHCiON: 

SetROIState (S^lOGOPFSEHT) ; 

SendLogoff ((long) lF_OE'aCm); 

oreak; 

} 



/• Moduie ; rdUogon.c ,| 

/• Routine: void LOCAL KeyBoardState (-0R0 KeyBoardSUte) •! 

^' called -hen the keyboard state changes and then ta«es action •! 

/• according to ROJ spec , 

/• Return : J 

:; 

void LOCAL KeySoardState (WORO Key8o«roState) 

*if defined (OEBUG) 

printfCOM^KSOSTATE Xd\n- , KeyBoardSUte): 
•ervlif 
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(CctProfU.int ("AATr. -K««pAlW«-. i) » O) 

9if d«fin«d (oeauG) 

Pfinif(- ignore keep 4ltve\n"); 
•end if 
fturn; 



switch (statt) 

{ 

cast «_IMACTIV£: 
case S'OAWTACTIVE; 
cast S^LOGGEDOFF; 
caa« S^OUERYSENT: 
cast S_OUERYWAIT: 
cast S_L0GOFFSENT: 
cast S^LOGOFFWAIT: 
cast S_ACTtVE: 
cast S^OARTLOGCINGOM: 
cas* S_ROTSLt)GGlMGOM: 

SetllOIStatt (S LOCOFFsemT); 
(KeyaoardSUte s= O) 
Logoff Reason ^ if ^BCFAtL: 

etst 

lo^ffRtason 5 LF^KBCXIK: 
»»f defined (DEBUG) 

•enS^r*'*"'^*''*"*''*' " l-o9offRe«son); 



SendLogoff (Logoff Reasc- . 
break; 

} 

) 



/« Module : ral logon. c * «•••••••••••#•••••••••/ 

/. Rowtin.: void LOCAL ROiS.==«-.y (t«MO hWnd, NORD nRtsult. long IParai.) 1/ 

" r Tor^^^i!--^^^^ -"-^^ --Ls 

/» Return : void *^ 
/• •/ 

vo^d LOac ROISLoRepiy (wnO --no. wQRO nfle»wu!"^'*plr«r"""""' 
»*f defined (OEeuG) 

OrintfCROlS LO REPLY\ft ); 
•endif ~ ■ 

switcn (state) 
( 

cast S^OARTLOGGIMGOM: 

/• first cneck r«5ji: c' togon •/ 

switch (nResult) 

( 

case 10 jm: 

SetROlStaie (S ROTSLC03:sGC3N) ; 
TellftOTStogon TlPara-. 
braak; 

case LO_,REjeCTEO: 

iL^J^ [>« '»ntd IS go oack to logged of status •/ 
SetROIState (S^lOGOEXpF) , 

b^«^^^"^ <'«O.S-"UP. OH^ERRORTEXTOIALOG, hWndOlalog. (long) K.BAO.DtR.IO) ; 

case lO^ALREAOyQN: 

SetROISUte (S.LOCGEX-?) ; 

brw?"^*"'' O-e-WOftTEXTOIAlOG. hWndOialog. (long) TC.OLR.ON.T^CE) ; 

) 

break; 

/• dont ranovt dialog as us not on anpUy ■/ 
case 3_0ARTACTIVE; " ^ ' 

/• "rst check result of logon •/ 

switch (nResult) 

case LO.NONTRAOING: 
case Lo"linE0OWN: 
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/• ROTS reoons lire oown but OAflT can carry an •/ 
•if defined (OCBUC) 

printft'TOTS dOwrtVn"); 
•«ndi f 

StCROISUte (S OAATACTIVC): 
brtak; 

cas« CO_OK: 

SeCROIState (S ACUVE); 
•if defined (0€BUC) 

printfCfiOI: everyoooy logged on and happy !'»<\n-l' 
•end if . - . \ f . 

.break; 

caae tO^BAO TRADER: 
break; 

case tO_ZHHi61TED: 

break"* * "essage as logon box Is not displayed •/ 

case tO^tOGOFF: 
case LO^REJECTO): 
break; 

) 

break; 

c»»« S^ROTSLOGGIKGON: 

/• first check result of logon •/ 

switch (nAesult) 

{ 

case LO^NONTRAOIkG: 
case LO~LlNE0OkN: 

/• ROTS reports U«e c;-n but OART can carry on •/ 

• tf defined (CE3UG; 

printf(-R0T5 line =c-n\n-); 

•endlf 

SetROtStatft (S^0aR7ac::.E) ; 
£ndLogonOialog*t). 

CtrlSenOMcssage (KJC^Zi:;!. rqis ALLLOGGEOON, 0. 01): 
break; ' ~ • 

case LO^OK: 

SetROrstate (S.*Ct:vE). 
£ndt.O9on04atog~(}; 

CtriSendMessage (M00.3Air. qoiS AULO06E00*#. o, OL)- 

ROISSenoMessage (nKno*»ors, ROIS'alllOGCEOOM 0 OL)- 

SiJ'^Jtl^^^reai^'^'''^* "H-«0IS.F0CUS.5wiTO;. RoJs_ACTIVATE.ROTS. OL); 

prIntfCROI: Everybody logged on and happy !!!!\n-); 
•end if * 
break; 

case LO_BAO_rRAO£R: 

SetROIStaie (S_LOtiC£0OFF) ; 
Oartid » Getke^ld (OaRT). 

CtrtSendHessage R0l5_L0G0fF. OartW. (long) LF USER): 

Crt'^r2*ni:2?;r'r; hw«0Uio5. (ioAg) TC.BAO.TRAOERIO); 

/ >eii oiaiog handler to display error •/ - - • 

break; 

case LO.IMHIBITEO: 

/•log OARf back off ■ 
S«tROIState (S^LOGGEXFS) , 
Oartid 3 GeUfe^ld (CART); 

CtriSendMessage (HOO,CAflT. ROIS.LOGOFF. Oartfd. (long) LF USER); 

CtriSendMessage (m0O,S£1UP. Oh^ERRORTExtoiALOG, hWndOlaloi. (long) TC,ROTS,IKMIBITEO); 

case LO^LOGOFF: 

eMS??? *° ^ ^^'^ ^® of status •/ 

SetROIState (S^OGOEOOFP); 

Oartid » GetNewld (Oart), 

CtriSendMessage (HOO^OART. ROis.'.OOOFf . Cartld. (long) LF,US£R); 
case LO REJECTED: 

Oartid » 6«tNe»Id (DART); 

CtriSendMessage (HOO_OART. RDIS LCGOFF, Oartid. (ionq) LF USER)- 

b^M^'^'^"^ ''^O-SETUP. CkJrrortExTOIALOC. hWndSialoi. (lo;i9) TC.BAO.PASSkWO); 
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S«tPOXSUC« (S^LOCGEOOFF) : 

Ctrl5€n<jM«s»A^ (mOO.SETUP. OM^ERRORTEXTOIALOG, hWodOialOfl, (Long) TC OlA OM TKICE): 
StndLogoff ((long) If IHPERATWO: - - - 

) 

bre«k; 

) 

) 



— 

/• Hodut* : rdllogon.c 

/• Rowttfw: vo4d LOCAL ROIStoggacOf f (hwo hW«S. MORO wid) •/ 
/• handlea th« ROIS_lOGG£0_OFF messages •/ 

^* •/ 
/• Return : void -y 

.-. : 

void LOCAL ROISLoggedOff (HW*0 h*i«d, wORo wid) 

ilf defined (DEBUG) 

pfintt("ROIS_tOGG£0 OFF\«-), 
lendif 

switch (state) 
{ 



case S^OART ACTIVE: 
• ff'deflned (DEBUG) 

pr1ntf("iine down ar«o 'c*.* logged offNn')- 
•tndlf 
break; 



case S.LOGGCDOFF: 
case S^ACTIVE: 

/• if in this state tne*- isoff has been aborted •/ 

break; 



/• first reply froo sooeone • 
case S^LOGOFFSENT: 

if Nld =3 Oartld It ^Iz -i =:it3ld) 
setmistate (s LOGOF^.i:--. 

breek; 



/• second reply therefore pes -c siaLog •/ 
case S^LOGOTFWAIT: 

SetPDIState (S.LOGGEOOFF). 

/• only for debugging snouid not be send unless both parties eggree •/ 
if (ROTSPrescnt) 

CtrlPostMessage (mOC.SEToP. OM STARTDIALOC, hWnd, MAKELCnG (SO L0G(3H, 01): 
els* " 

CtrlPostMe«s»9« (HOD^SETUP. Om STARTDIaLOG, hWnd, KAKElOsQ (SO QiKHtSE DEALER. 0)): 
break; 

) 

) 



/• 
/• 

/• Return 
/• 



/ 



/• Hodule : rdUogon.h ,^ 
/• Routine: void LOCAL ROIStoacf M*s^est (hwmD hwnd) •/ 
processes a rei|uest ''sn cart or ROTS to I09 off •/ 



void LOCAL ROlSLogoff Request (.o-g Reason) 

■ If defined (DEBUG) 

printfCRDlS L0G0FFRE0uE5T\n ; 
■ei^lf 

/• If -e have received a OM_STa^t n-essage and one or other of tne events 
•^have happened then *•« can start initial logon sequerve 



•/ 



If (GotOKStart &i (RegTimerExpi <-eo :; ROTSP-esent) } 

switch ((MRO) Reason) 
{ 

case LF^STARTUP: 

/* starting up so force logoff •/ 
/• save reason for logoff mssage •/ 
SetROIState (S_LOCOFFS£MT) ; 
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S«ndLo9off (Reisoft); 

break: 
dafsult: 

/• raasen for {ogoff message ■/ 

Logoff Reason = R«ason; 

SetPDIStata (S^OUCRYSENT) ; 

/• post messagfts to OaRT and ROTS reouestlng that they log off •/ 
Oartid s GatN*«Id (Oart); 

CtflPostMessage (mOO.ORT. ROIS,OU£RYLOGOFF, Oartid. OL) ; 

. /■ iftjst irakt sur« that f"* oost gets through •/ 
Rdtstd 3 GetNewId (ROTS); 

whUe (PostMessage (hWxjROrs. ROIS OueRYtOGOFF. Rdtsld. OL) --s 0) 
printf t»fti£Re 'RDI Pastnessage faUedVn"); 

t»re«k; 

) 

) 

) 

/.«..«....«..„..,....»... .........•,..•......••..•„«,.„„.„/ 

/• HoduU : rdi logon. c 

/• Routine: void LOCAL ROISOl resonse (mwhO hWnd. WORD wid. WORO nResulC) •/ 
/• • handles ROIS OLReSPCwSE message »/ 

' •/ 
/• Return : ' 



void LOCAL ROISQI resonse (wrfNO --lo. <IRD wld. wOftO nResuit) 

•if defined (OESUfi) 

Orlntf ("ROIS OLRCSPCnSs - 
•endlf 

switch (state) 
{ 

case S_LOGGEDOFF: 
case s'aCTIVE: 

/• If In this state z-c .ogoff has been aborted */ 

break; 

case S (AlERYSENT: 
{ 

/« check result of irgs-* •--juiry •/ 

switch (nResuit) 

{ 

case OL.STOP: 

SetROISUte (5_ACTlve); 

/• tell setup t^at f*e logoff has been aborted •/ 
ClrlSendMessage {K»_ScTvP. tX exTRM DIALOG A80RT£D. 0, OL): 
break; - - - 

case OL.ACTIVE: 

/• abort logoff ano set suie back S ACTIVE «/ 

SetROISUte (S^ACTIVHJ. 

if (wid as Oartid |i -To »s (Idtsid) 

CtrlPostHessagt i?<'3_S=TjP. OH^STARTOIALOO, hWnd.KAKEtOHG (SO ACTIVE CON VS. 0)): 
break; 

case OL^OK; 

if (wFd «3 Oartid i* , sczsid) 

SetROIStace ,S 
break; 

) 

) 

break; 

/• **«1t for the otner party to '•piy •/ 
case S^QUCRYVAIT: 

switch (nResuit) 

{ 

case Qt_STOP: 

SatROIState (S_activE), 

/• tell setup tnet the logo'* -as oeen aborted •/ 
ClrlSendMessage (hOO SE'wP. > txl^ OIAlOC ABORTED. 0, OL); 
break; ~ 

case OC^ACTTVE: 

/• abort logoff and set ROl state back 5 ACTIVE •/ 

SetROISUte (S^ACTIVE); 

if (wid M Oartid || wid s» Rdtsld) 

CtrlPostMessage (hOOJETUP, 0K_STARTOIALOG, hWrvi, MAKE LONG (SO ACTIVE CONVS. 0)); 
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break; 

cu« OL OK: 

C 

/• requwt frtm ROTS to rwv. th« Arm you sur. diatoa 

* but I .111 ltav« xrm cod« m cas. their «,n^. ^ 

• ara changtd 
•/ 

«1f 0 

WORD result; 

SetftOIStatt (S INACTIVE)- 

■r^U 3 (VOROT Ctr,S..OH„sa,. ,KH,.SETUP. CH_ST*Rr0U.0C. n«„.. ^.ELONO («..AH«0«««. 0„; 

/• If UMr says yes cnen #in»sn logoff •/ 

1' (result " lOYES) 

{ 

S«tHOIStat« (S.IOGOFPSENT), 
5«ndt09off (Lo^offfteason); ' 
break; 

) 

/• tf no then go back to active •/ 
•ls« If (result S3 lOhO) 
SatRorstate (S activC); 



«etse 



tendlf 



/. If result is something different then do nothing ./ 



break 

/• do It the old wav •/ 
SetROIState (S.LOGOFfsesT) ; 
SendLogoff (Logof f Reason j 
break; 



} 
} 

breek; 

default: 
break; 

) 

} 

/••••••■••«t«f 

/• Module : rdUogon.c ...•.•.„„/ 

/• Routine: void LOCAL ROISStatus («OR0 r.ason) 
^" processes the ROIS.STatuS inessage 

/• Return : void */ 
/• •/ 

•/ 

void LOCAL RDISSUtus (UORO reason) "••""••••■ — "••••••••......•.«...«/ 

•If defined (DEBUG) 
^^^J^fttfC-RS^STATUS M\n-. reason). 

switch (state) 

{ 

case SJNACTIVE: 
case S^OMTACTXVE: 
cese SjaoERYSEHT: 
case SJXfERYVAXT: 
case S.LOGOFFSDiT: 
case S^LOGOFFWAIT: 
case S_ACTtvC: 
case S'OARTLOGGIMGOM: 
case 3.R07SLOGG1NGOM: 
switch (reason) 

/• hsrdle as If detached has cee'* aetected •/ 
case RS^IKPERATIVE: " ' 

SetftDISUU (S,LOGOFFSE«<T), 

SendLogoff ((long) lF lKPeq*r;.r) 

break; 

case RS^OISCOMHECT: 
KeyeosrdOetached {); 
break; 

case RS^HOSTSMUTOOWl: 
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SetflOISUts (S OARUCTIVE): 
Rdtsid « G«tM«wId (ROTS); 

R0ISS«ndMe3S«9« (hWndROTS. ROIS^OGOFF. Rdtsid* (longjtF kOSTSHUTOOWN) ; 
break; 

CAS« ftS^HOSTLOGOfF: 

Sct«OIStat« (S.DARTACTIve); 
RdtaXd » 6«tNt^Id (ROTS): 

ftOXSSendH«SM9« (hWndROTS. ROIS LOGOFF, Rdtald, (Loog)LF HOSTLOGOFF) ; 
break; 

case RS_LINC0OWN: 

.S«tROIStat« (S.DWTACTIVE) ; 
Rdtsid s G«CMewId (ROTS); 

R0I5S«ndM«ssag« (hWndROTS, RDIS LOGOFF. RdtsId, (long)LF LlM£DOWN); 
br«ak; 

case RS.LXNeUP: 

/• 1 wUl $«t tha state but if tin* It coonlng up then 
• dart only is running and «• should already be In this state 
•/ 

SetROIStat* (S DARTACTIVE); 
TallROTSLogoo TOL); 
break; 



casa RS_UNIKHIB1T: 

/• 1 understand that this cant happen •/ 
break; 

) 

break; 



« Module : rdl logon. c •/ 

• Routioa: static void tOCAL S«'.ftOI5Ut« (ROI_STATES s) •/ 

• sat5 the state of the logon code * •/ 

•/ 

• Return : void •/ 

•/ 



static void LOCAL SetROIState (RDt^STATES s) 

•if defined (OCBUG) 

pnntf( "State Xs -> Xs\i\\ pStatelstaU) , pSUte(sJ); 
•tndlf 
state « s; 

) 



le : rdllogon.c ./ 
> Routine: static void LOCAL SandLogoff (long IReseon) -/ 
• sends a logoff request to ROTS and OART •/ 

-/ 



• Return : void 



static void LOCAL SendLogoff (long iReason) 
I 

LogoffReason « L Reason; 
Cartid a GetNewtd (Oart); 

CtrlScndMessage (MOO OART, aoiS LOGOFF, OartZd, LogoffReason); 
RdtsId a GetMewId (ROTS): 
^ ROISSendHessege (hWndROTS, ROIS.LOGOFF, Rdtsid, LogoffReason); 



/...«............•......«,.....,.„„...„.„„„.„.„„„ „..., 

/• Hodule : rdilogon.c . •/ 

/• Routine: static void LOCAL TeliROTSLogon (long IPeran) ■/ 
/• copies data frooi DART logon and instructs ROTS to logon «/ 

/• ./ 
/• Return : •/ 
/. -/ 

/"•"• • ..•.•.........,„...,... ./ 

static void LOCAL TellROTSLogon [long lOaram) 
{ 



/• log on is required so copy data and send a message to setup •/ 
HANDLE hROIcopy s KIWORO (IParMi): 
Int offset 3 LOMORO (IParam); 
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HANDLE hMyeopy; 
LPtOGON.OATA icMycooy; 
LPLOGOr^OATA IpROIcopy; 
WORO lO90niSourc«; 

hMycopy = GlobalAiioc (GMNO | GH&i SHARg, (long) siztof (LOGON OAT*)); 
rF,PAlUD.exiT(hKycopy, FTl NO tOGON KHM); 
ipHycopy 3 (tPLOGOH.OATA) GlobaUocMhHycopy) ; 
IF^FAIUDJXIT (IpMycopy. FTl MULL POINTER); 



switch (state) 

{ 

case 5 ftOTSLOGGlNSON: 
( 

IpRDIcooy » (IPLOCON DATA) GlobalLock (hftOIcopy); 
IP.FULEO.EXIT (LpftOlCOOy, f TL_MULt_POlNTER) ; 

/• f<m allow for offset if there I3 any, blaae the designer for all th1« 
• wtting about wttn offsets 
•/ 

IpROIcooy = (LPtOGON_OATA) <(LPSTR) ipAOXcopy ♦ offset); 

/• make a copy of the oata •/ 
• IpMycopy » 'ipAOIcopy; 
LogonOata 3 •IpftOIcopy; 

/« set packet ourkers «/ 
lpHycopy->stJi = STX; 
lpMycopy->et3i e ETX; 

/• logon from dialog box •/ 
UgonSource » l6_080X; 
GLobalUnlock (hAOTcopy); 
break; 



case S QAATACTIVE: 
{ 

/• «eke a copy of the =a;a • reclved at the Last logon •/ 
•IpHycooy » logonOata; 

/• set packet meriters •/ 

lpHycopy'>stx a STX; 
lpMycopy->etx 3 €TX; 
/■ logon fro* lineup •/ 
LogonSource 3 lG AUTO; 
break; 

) 
) 

Globaiunlock (hfiycosy); 

switch ((WO) ROISSendMessage (hWndROTS, R0I5_L0«, LogonSource, KAKELOWC (0, hMycopy))) 

case lOjOK: 
break; 

case LO^BAOOATA: 

OartFetaiexIt (FTL_Ba0 LCSOU OATA); 
break; 

case lO.alrEaovON: 

Dart?atalEMii (FT;. ALRl^zy Ok) ; 
break; 

default: 

OartFatalExit (FTL OAO AEotv);- 
break; 

) 

GlobalFree (hMycopy); 
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